到目前为止, SSDB 还是一个单机存储方案, 存储容量受到单机硬盘的限制, 虽然 SSDB 可以自动压缩数据, 将存储容量提高 10 倍以上, 但还是在 TB 级别. 不少 SSDB 的用户一直在呼唤 SSDB 分布式, SSDB 集群, 但是千呼万唤不出来. 为什么?
分布式数据存储是一个真正的技术难道, 不说各种理论, 最简单的是数据怎么迁移. 想想, 原来你只有一个存储节点, 但数据多了之后, 硬盘存不下, 这时怎么把一部分数据迁移到另一个新的存储节点? 这就是数据迁移问题. 这其实是2个问题:
1. 一份数据应该存储在哪个节点? 原有的节点, 还是新加入的节点?
2. 在什么时机, 用什么手段来迁移? 如何保证迁移的过程不影响服务?
有些同学一听到分布式数据存储, 就言必称"一致性哈希", 遇到这种人我只有一个字 - 滚!
天生支持异步编程的语言如 NodeJS, Golang 等, 创建一个异步 routine 的成本非常小, 这确实是一个非常方便的功能. 比如用在网络爬虫程序的开发, 对于每一个要抓取的 URL 就启动一个 routine, 类似启动一个线程, 既能充分利用 CPU 多核, 代码也很简洁.
正因为太方便, 所以常常被滥用, 并引发许多严重坑. 下面分析一下.
写异步编程的程序员是爽了, 但维护数据库的 DBA 却要哭了. 异步编程程序员每一个查询可以轻松的异步, 但数据库的处理能力就那么多, 最直接的后果是数据库挂了. 回到网络爬虫的例子, 如果爬虫本身不做控制, 可能就把对方的网站拖垮了.
大部分程序员都听说过 TCP/IP 网络协议, 或者都写过 TCP socket 网络的程序, 甚至还学过 TCP 原理, 少部分看过 TCP 协议的某一个实现版本. 不过, 真正掌握 TCP 原理及思想的人, 我觉得不多. 只有理解了 TCP 原理及实现, 并且把它背后的思想和技术活学活用到其它的领域, 那才算是真正掌握了 TCP.
TCP 协议的目的, 是在不可靠传输的 IP 层之上建立一套可靠传输的机制, 它所应用的技术, 如滑动窗口, 慢启动, 指数退避, Negal 算法等, 都是优化目的.
今天参加了一个和某网游开发团队的交流, 感受到了网游开发和 Web 开发之间的巨大差异, 所以我写了本篇博文.
传统的网游开发者可能由于更大的精力放在游戏逻辑上面, 并且因为游戏客户端是一个高度内聚逻辑复杂的终端程序, 所以网游开发者在开发服务器端的时候, 也容易把客户端的经验放在服务器端, 很少考虑动态可扩展性和服务容灾性.
Web 开发的一些经验对网游服务器开发是非常有用的:
1. 服务(子系统)无状态化,
2. 所以服务可以采用 Web 模式来开发, 也即 Web Server + 脚本语言 + 存储
服务(子系统)无状态化是整个系统动态可扩展性和服务容灾性的保证. 例如在 Web 系统中, 一个全静态内容的网站是无状态的, 只要部署了多个服务器, 那么用户访问任何一台服务器都 OK. 这个例子说明了服务无状态化是系统可扩展性和容灾性的保证, 同时也隐含了一个要求: 数据是同步的.
网游程序员会立即提出疑问, 你举的例子是静态网站, 但网游服务器的子系统可不是那样的, 能实现无状态化吗? 比如, 用户连接到了某台网游服务器, 这台服务器上面会保存有这个用户的很多信息数据, 如果用户断开连接再连到另一台服务器, 那他的数据不是全丢了吗?
其实, 如果把服务分成逻辑(指令)+存储/状态(数据), 那就可以把有状态的服务改造成无状态的服务. 因为一般的网游服务器把逻辑和存储绑在一起, 所以做不到无状态化, 所以, 也就无法动态地增加了减少服务器.
一旦把逻辑和存储分开(如 PHP + MySQL), 就可以使用 Web 技术来开发网络游戏服务器. 逻辑本身肯定是无状态的, 所以可以任意添加和减少服务器和实例. 而存储本身经过开发, 也可以做到无状态, 如 MySQL 集群和其它的存储群集. 把一个有状态的服务改成无状态的服务, 可以通过简单地把逻辑和存储分离即可.
著名的 C10K 问题提出的时候, 正是 2001 年, 到如今 12 年后的 2013 年, C10K 已经不是问题了, 任何一个普通的程序员, 都能利用手边的语言和库, 轻松地写出 C10K 的服务器. 这既得益于软件的进步, 也得益于硬件性能的提高.
现在, 该是考虑 C1000K, 也就是百万连接的问题的时候了. 像 Twitter, weibo, Facebook 这些网站, 它们的同时在线用户有上千万, 同时又希望消息能接近实时地推送给用户, 这就需要服务器能维持和上千万用户的 TCP 网络连接, 虽然可以使用成百上千台服务器来支撑这么多用户, 但如果每台服务器能支持一百万连接(C1000K), 那么只需要十台服务器.
有很多技术声称能解决 C1000K 问题, 例如 Erlang, Java NIO 等等, 不过, 我们应该首先弄明白, 什么因素限制了 C1000K 问题的解决. 主要是这几点:
计算机编程领域有个公式:"程序 = 算法 + 数据结构", 其实, 换个角度看, 那不就是:"软件 = 逻辑 + 存储"吗? 今天就谈谈存储(数据)对于软件设计的影响.
很多偏业务应用型软件, 在数据规模非常小的时候(例如 100M 之于 8G 的内存, 10G 之于 1T 的硬盘), 怎么做都不会是问题, 只要逻辑正确, 程序一启动, 立马就顺利地提供服务. 比如开发一个日活跃 1000 人的论坛, 随便找到虚拟主机, 用 PHP + MySQL 就出来了, 成本低廉性能稳定.
|
带有此标志, 表示本博客已经被加入到IT牛人博客聚合网站. |
Loading ...