之前几天说过，因为经典iocp实现（以下简称经典实现）多个io线程绑定在一个iocp上，这样内部管理了iocp队列的处理，内部决定是不是需要线程切换，我上次修改的一个版本（以下简称实现2），用了多个io线程，每个iocp队列仅绑定一个io线程，一组用户共享一个io线程，这和经典的多线程epoll模型的做法是很相似的，这样每个io线程是可以独立控制了，但理论上这种做法没有发挥iocp自动管理线程切换的优势，昨晚没事用这两种实现分别做了个echoserver测试了一下，这两套实现代码仅40行左右不同，其他完全一样，效果真的是差很多，测试仅用一个进程模拟了4000个客户端，每秒1个包，先看实现2的，cpu占14%，2个io线程，1个accept线程，1个主线程，其他线程都没干活闲置。

再看经典实现，cpu几乎一直是0%，2个io线程，accept也是在io线程里面处理，其他跟实现2一样，测试客户端也一样。

说实话，在测试之前我也没想到有这么大的差距，经典实现就是1.2w个连接连上来还是这样，就是内存占用多一点：

习惯上总有人喜欢拿epoll和iocp来对比，我到现在也没看到真正公平的对比，就算是相对公平的也没见到，因为在我看来，要对比硬件应该是一样的，os都应该是最新的，最重要的是，server端程序应该都是发挥了各自优势的，如果拿我这里的实现2去代表iocp的水平和epoll对比，势必造成比epoll差很多的结果，然而这显然是不正确的。

epoll经典多线程模式实际实现和实现2很相似，理论上也有类似的线程切换问题，不知道效率怎样。

回调函数实在是用得太广泛，回调函数又有多种实现方式，如：

1、  静态函数

2、  虚函数

3、  函数对象

4、  传统c函数，通过一个void *传递对象地址，内部强制转换

5、  fastdelegate

6、  Tr1::function + bind

7、  Boost::Function + bind

基本上速度是按照由快到慢的顺序排列的，就是

1 > 2 > 3 > 4 > 5 > 6 > 7

其实234速度很接近，有的时候函数对象效率更高一点，基本上越是高级的方法使用起来越方便，但速度越慢，越是传统的方法速度越快，呵呵，看来做server端程序要综合考虑效率太新的东西还是要少用啊，还是用传统的方法比较靠谱一点，当然如果调用次数不多的地方，使用更方便的方法还是好一些，毕竟我们要综合权衡，而不能死板恪守教条。

之前设计了一套网络框架，持续改进了很多年，使用在很多项目上，综合效率还行，也很稳定，一直以来对这套东西信心满满，总以为啥问题都好解决，但最近就有个需求让我选择还是改了下这个框架。

之前的框架是这样的，可以开一组N个io线程，可以开一组N个同步线程（默认1个），可以开一组N个异步线程（默认1个），可以开一组N个timer线程（默认1个），可以开一组N个异步线程（默认cpu个），每组可独立受控，每组可支持自定义消息，可支持timer，一组N个如果N大于1则无法直接给这组里面的特定线程发消息，只能给一组发消息，这个组里面会选择某个合适的线程处理这个消息，这也是iocp高效和典型的用法了，但这也正是问题的结症所在。

Linux下的多线程服务器更常见的做法跟这个不大相似，一般都是将某些socket分配到某些线程epoll，分好之后就是固定的，不再变化，跟Iocp将socket绑定到一组线程的做法不同，由于某个socket直接绑定到了某个线程，所以有些问题就变得简单了，如同一个连接的在同一个线程内消息进行了同步，要跟io线程绑定私有化数据也简单了，而且每个线程可独立受控，所以很容易实现一组io各自挂tls（线程局部存储）数据，而我现在做的这套框架就是这方面不好控了，其实也很难说这两种意义上的框架到底谁更优，如用在web型应用上这种socket被一组io线程管理的模式很方便效率也高，但我现在的需求需要某个socket使用线程相关数据，以避免数据之间的锁，我用内存换时间，由于在原来的框架上增逻辑难以实现可直接控制io线程的框架的，所以花了一个晚上重新改写了一套框架，在原来iocpframe的基础上派生了一组带2名称的类，除替换类名之外只修改了几十行代码就做好了，总的来说花的时间还是比较少的。修改后io线程一组，但独立受控，外部可对这组线程中的某一个直接发消息，基本满足了需求，现在要给每个io线程绑定私有数据并触发特定消息比之前简单多了，而且绝对无锁。

由于原先的appserver功能不断增多，最近又增了两个功能，需要不断从后端memcached中提取数据并进行计算，由于提取数据量大且频繁，导致效率很低，粗测了一下，获取数据和格式化等操作花了90%以上的时间，由此设想将memcached改写或重写一个支持memcached的服务器，将计算功能和memcached做到一起，让获取数据的路径最短，也就最大限度减少了数据传输和格式化等操作，就是类似存储过程一样啦，这部分可以考虑使用插件来实现，甚至可考虑使用脚本语言来实现。

网上搜了一下，果然发现早有人这么干了，正所谓英雄所见啊，呵呵。具体方法倒很多，自定义key命名，根据特殊key在get、set、replace上做特殊操作，或者根据命令中的flag等做特殊处理，或者扩充stat命令等，都是可以的，我们暂时就考虑修改特殊的键值做特殊处理。

要做一个完备的既支持ascii命令又支持binary命令的兼容memcached还是有一点点麻烦的，我暂时也没有太多需求，所以就仅支持了ascii命令，其实也是考虑支持ascii的客户端更多，各种语言的支持mc的客户端数不胜数，但大多只支持ascii命令。由于我之前为了测试服务器框架效率，做过一个支持ascii命令的memcached兼容版本，因此拿过来直接使用太方便了，这个版本的实现其实很容易，如果有一个较好的框架代码的话基本上在一天之内可做完，当然要做到很好可能需要多花一些时间，我现在做的也不是特好，要完全取代memcached使用还是有些差距，主要是一些过期机制等没完全实现，虽然速度上比标准mc版本还要快一点，呵呵，因为暂时的确是不需要这些过期机制，所以也没打算这个版本实现，其他功能基本上都有。

以后准备将这个memcached解码部分作为一个单独的解析器，和支持其他协议一样，换上这个解析那就支持mc协议了，还是很方便的，以后有空还是要做个支持binary协议的，以便可以更高效的解决问题。

想到server能支持Memcached协议真是好啊，客户端基本只要用个libmemcached就好了，多服务器分布，容错，多份数据啥的都有现成的解决方案，只要把server做稳定了就基本ok了，对咱这种小团队来说再合适不过了，节省了很多开发维护成本啊，现在内存这么便宜，部署几个点实在是很easy的问题。

最近要将一些数据放到内存里面做很高的并发操作，考虑了很多方案，

1、 简单点使用map hash_map等自己管理。

2、 用sqlite内存表。

3、 用fastdb内存数据库。

4、 用ExtremeDb，TimesTen等。

比较测试了一下123，发现还是自己实现速度最快，比fastdb模式快3-5倍，fastdb模式比sqlite内存表模式快10倍左右，由于自己实现不具有典型通用性，多线程下访问效率会下降，要管理多线程下各种更新查找等还是比较麻烦的，所以在1和3方案之间纠结。

为了使得决策更好一些，暂时还没做决定，顺便到万方等上面搜索了一些论文来看，看来看去看得真来气啊，虽然都叫内存数据库但各种实现的都有，有用gdbm来做的，有直接map管理的，有hash管理数据的，有t树管理的，有数组队列管理的，有的明显就是个不大变的东西还弄个啥事务的，靠，刚刚居然还看到一篇鸟文《电网监控系统实时数据库的设计与实现》里面的测试居然是1000条，插入时间80毫秒，真可笑啊，区区这么点数据也好意思测，还要花80毫秒，还自以为很快，这个速度至少可提高1000倍以上啊，这帮垃圾，写的啥鸟文章，研究个屁啊。

看完这十来篇论文，俺的思绪又回到1999年，当年我给别人优化过一个电信计费的软件（看的论文里面有好几篇讲电信计费的），当时有个朋友的朋友拿了个需求过来，7000万条记录，原来计算费单要花十几个小时吧，我帮他改了下，十来分钟就算完了，朋友很满意，当时的做法很简单，就是弄了个mmtable，大体就是跟map类似的东西吧，那个时候map还没流行起来，俺也不知道，所以就自己弄了个内存表，内部基本就是二分查找了，那个时候我对hash都不大熟悉，B树之类的算法刚接触也不会用，就这么个东西当时的电脑也只要花十来分钟，我估计就算是那个老程序放在现在的普通台式机上要不了几秒钟就可算完。也不知道这么几千万条记录的小需求怎么在这帮人眼里就成了什么海量数据，对俺来说跟玩似的，区区几千万嘛，不过是俺拿来测试用的。

去年中做了个md5 hash反查的东西，数据都是几百亿到几万亿的，后来的效果就是一个文件可存万亿记录，一次查询平均1.2次IO，即使全放在SATA磁盘上也就十来毫秒而已。

区区几千万条记录咋就叫什么海量数据呢，海量个毛啊，内存都放得下的叫什么海量，现在服务器动不动都是几十G内存，区区千万根本算不上什么，查询定位都可到微妙了，1秒插入至少千万条了，居然还看到1000条插入的测试，真是不得不佩服国内这帮垃圾研究生的水平，也不知道这种论文咋就能通过审查，只能得出结论他们的老师也都是猪。

         骂归骂自己的问题还需要继续努力，对咱目前的需求来说自己管理数据，即使一个线程都搞得定，因为不过区区几个表，几十万条记录而已，不过这种10年前咱就会的技术还真是拿不出手，怎么的也得做得更好一点，呵呵，继续研究吧，多线程下内存数据库，从概念上看的确是个很有吸引力的东西，要是性能跟得上，其实在很多地方可以取代普通的数据结构用法了，可以大大减少编程难度，甚至我在想如果有个支持事务的内存数据库，之前设计的cad类软件的undo/redo都可以用事务来实现，完全可以抛弃先前设计的复杂结构，其实这种东西即使不用内存数据库就算是用个sqlite都完全能搞定，唉，往事不堪回首啊，看来数据库方面的确得多花功夫，特别是多线程和分布式模式下的内存数据库。

最近给自己换了个老板，忙了一段时间，所以有几个月没写博客，今后还是要争取多写啊，呵呵。

换来新地方，第一件大的事情就是修改后端架构和通信协议，架构也设计得很普通，因为这边的业务不需要太过复杂的后端，所以就简单设计了一下，基本是参照web的模型，符合我一贯的向web学习的思想，弄了个gate管理入口，相当于web下的webserver，后端其他服务器挂在该gate下，相当于web模型下的appserver，或者fastcgi模型的fastcgi进程，gate上管理连接、合法性检测、登录、加密、压缩、缓存。Gate和后端通信本来想参照fastcgi协议，但看了之后觉得fastcgi协议还是复杂了，所以就设计了一个更简单的协议，gate和后端server之间可传递key:value型数据对，value不局限于字符串，可以是任意数据，这样基本满足了当前的需求，第一版放上去之后也运行良好，到今天也基本持续稳定运行快一个月了，没出过什么事情。由于在gate这边缓冲了job管理，所以后端server升级很方便，随时可关闭更新，gate会在窗口时间内将未执行完成的任务重新提交，有此功能可放心大胆的升级后端，这个月这样的工作做了几次，在架构修改之前这样的事情几乎是不敢做的，因为一旦升级所有用户全部断开连接，而现在用户则基本无感觉。Gate上的缓存层为后端减少了一些压力，这个缓存是按照请求的md5为key做的，并根据协议配置时效，有此cache后端大多数服务可不设计缓存或降低缓存设计的复杂度。Gate上针对敏感数据统一做了加密处理，主要是辛辛苦苦整理的数据不能轻易让竞争对手窃去了，呵呵。Gate也做了压缩，现在是针对>=128长度的包进行压缩，使用了qlz，压缩效率还是很不错的，速度很快。目前gate后端挂接的既有win上的server也有linux上的server，这是一开始就这么规划的，现在看来当初的目的达到了，混合发挥各自的优势，有的项目在原有系统上跑得好好的，没必要重新开发嘛。

协议设计上本来我是计划二进制混合json格式，以二进制为主，但尝试了一个协议之后发现，这边的小伙子们对直接操纵内存普遍技术不过关，他们大多是从java开始的，后来才学习c，对字符串用得很熟练，权衡之下采用了json为主，混合二进制为辅的方案，这样修改之后的协议和他们之前使用的xml类似，就是更小更紧凑一点，使用方法上很类似，从现在的效果看还行，使用json格式为主的协议当然不能跟使用pb之类的相比，解析效率上大约单线程每秒解析20来万10个obj的对象，速度上不算太快但也不算太慢，对付一秒至多几万数据包的应用来说还是够的，因为现在cpu计算能力普遍过剩，使用json的另个好处就是增删字段很方便，各个版本之间不需要太考虑版本的问题，要是全用二进制格式就要麻烦很多了，在使用压缩之后，目前的json格式协议比之前的xml协议减少了2/3的带宽使用，总体效果还是可以的。使用json调试也很方便，我提供了一个工具，写后端的就直接用该工具按照json格式收发数据，无需等client开发好了再去做后端，之后做client也很方便，请求发过去之后返回来的就是标准的json格式数据，同样的解析方法，每个不同的应用就按照不同的格式处理下即可，和web等模块交互也很方便，这可算是额外的好处了。

总之，虽然json格式存储效率和解析效率跟二进制方式还差半个量级到一个量级，但合理使用还是可以的，特别是跟xml相比优势很明显，权衡使用吧，当然追求极致效率可能还是用pb之类的更合适一些，或者自己设计tlv格式。