同步服务的设计和Tokyo Cabinet性能验证

 

    最近参与负责了一个异地部署项目，需要对现有的服务进行部分的重构，具体的架构设计后续有空和大家一起分享下，今天文章仅仅介绍一下用到的同步服务的设计上。

    这里的同步服务主要充当一个同步代理的角色，当服务的db或cache模块需要将修改的数据通知到其他部分的时候，只需要将同步请求发送给本机上安装的同步代理服务即可，剩下的工作就完全委托给同步服务来完成了。 同步服务会首先尝试推送同步包，当推送失败后，为了防止数据的丢失，就需要将数据保存下来了，所以设计的一部分就是如何选择数据的持久化方案了。

    同步服务对同步失败的数据存储，主要的需求实际上是类似于一个可持久化的队列服务，注意这儿所谓的队列服务，就是基本上读取和写入操作都是顺序访问，所以对文件io的性能期望还是蛮高的。

    刚开始的想法是为了避免自己管理一堆的存储文件，选择已有的开源db库，要求要尽量简单可靠，写入和读取性能要足够高。最终咱就瞄上了Cabinet 的Hash方式DB库，和其他key-value dbm比较，性能上均有很大的提升，官方的性能测试指标见http://1978th.net/tokyocabinet/benchmark.pdf   ，其中TC的批量写操作和读取操作的性能都是比较惊人的，不过本人向来是追求眼见为实，亲自进行了一些简单的测试，结果却出乎意料...

 

    由于是选择周末在家里抽空测试，所以测试环境搭建的比较简单，个人的笔记本，安装Vmware虚拟机，可用硬盘空间8G， 所以具体的绝对时间不具有代表性，仅仅用来衡量以下三种数据库状态下，批量写入操作的相对性能表现：

    (1) 数据库容量很小时候

    (2) 数据库容量大的时候

    (3) 频繁的删除，随即添加记录后

 

    首先测试写入的操作，分别统计写入100w条记录的耗时情况

   

DB状态	批量写的时间
空数据库	1.5 s
已经写入了200w条记录	1500s
顺序插入100w条记录	2.5s
在插入的100w条记录中随即删除和插入后，总量仍然保持在100w	2~3s

 

    最大的发现是，当db的容量增大200w级别，这儿由于测试机器比较破，假设放到正式的运营服务器上，估计这样的瓶颈会在千w级别的时候，写操作性能将会急剧的下滑，最终能达到1k/s这样的级别上。

   

    那么为什么当文件db容量大到一个阀值的时候，性能上会有这么大的反差呢，开始是怀疑文件太大，文件缓存等效果不是很好，为了验证这种情况，又进行了一轮简单的测试，这次测试不是针对cabinet, 而是使用简单的批处理写入文件，结果得到的性能指标基本上和文件大小没有太大的关联，而且速度上可以稳定保持在100w/s这样的级别上，看样，不一定是文件缓存的问题。

 

    又使用了Gprof进行了简单的跟踪，发现当容量大的时候，平均读取文件记录的次数翻了几倍，这个和官方介绍中的一致，当hash bucket小于总容量的时候，要想命中记录，至少会需要多次的io请求，由于这时候的io请求一般都是随机的读取请求，所以磁盘的io性能立刻降下来了（PS：磁盘的随机io性能主要和磁盘的寻道时间有关，一般随机读写的请求在500/s左右），最终，性能表现上就变得很不堪了。  解决办法也是有的，可以采用切分的方式，限制单个db的大小，当超过大小后，建立新的数据库，将记录插入新的数据库中。

 

    经过这么一折腾，又回到自身的需求上，发现自己并非需要如此重量级的dbm来实现持久化操作，简单的文件存储即可，所有的key，value均作为字符串，按照特定的编码格式存放在一行中，所有的文件均以文本方式记录，方便维护和管理。 同时，为了协调写操作和读取操作，建立公共的索引文件，记录当前所有日志的读取和写入位置。想想，也蛮简单的, 真可谓杀鸡焉用牛刀^_^.