消息存储系统

之前的一个消息系统使用的底层存储是je，java版的bdb（berkeley db），先赞叹一下，这产品的确牛！相关的中文博客（http://www.bdbchina.com/）。但是对于消息系统的存储来说，它有一些特点，用je的btree有些不合适，然后出了问题只能等死或去调一大推不熟悉的源码，还有licence的问题。所以一直在考虑，在空闲时间，根据消息系统的特点写一个存储，msgStore，至少在排错方面不会那么被动。

首先，消息系统的几个特点：

1. 消息的生命周期非常短，但又需要写文件，就怕那几乎不会出现的jvm崩溃。
2. 插入和删除非常频繁，几乎没有更新，读取至多一次
3. 外在表现像一个queue，先进先出，但是也会存在小量的反fifo

那么根据这些特性和一些性能考虑，对msgStore的取舍：

1. key/value，key为long，value是二维的byte数组，尽量的作为一个独立的模块，和消息的具体格式无关
2. 参考je的模型，划分多个db，每个kv属于一个db
3. 提供insert，update，delete，get等常规操作，不提供对不同key的批量操作
4. move操作，把指定的kv高效的在db间移动，避免delete再insert
5. ref操作，某个db的kv可被多个db高效的引用
6. 尽量提高写性能，读性能由使用者考虑，例如通过读缓存，预读等方法
7. 本身不提供读缓存，只有使用者才最清楚那些数据缓存可以最大的提高性能和什么时刻需要预读，如果是msgStore提供缓存，只能提供byteArray的缓存，还需要一次转换
8. 提供类似db的本地事务
9. 支持临时db，重启后该db的所有消息废弃

初步思路：

1. journal的形式，记录所有的操作，所有的操作都是追加到文件里，避免寻道
2. 一系列固定大小的文件 page，page个数随着kv的数目而增长或减小
3. 当page不被引用，可以被删除，page不会被重用
4. page有编号，编号能反映不同page里面log的先后顺序，编号大的page的log一定发生在page小的log之后
5. 约束page的顺序的一个好处，在删除废弃的page时，按照从小到大的顺序删除，在这过程故障不会导致数据的不一致。例如insert_kv1[page1],delete_kv1[page2]，当page1和page2都废弃，删除page1后失败，重新load时，只能load到delete_kv1，可判断kv1是被删除，之前记录kv1的操作的page被回收
6. create db，remove db等对db管理的log和kv分别存在不同的page，因为db管理log生存时间可能非常长，放在一起阻止某个page被删除，分为ctrl page和kv page，以后说的page都是kv page。db ctrl的log会非常少
7. 一个kv不能跨page。为避免浪费page空间，当kv大于一定的阀值认为是blob v，类似db处理blob字段的方法，写成一个单独的文件，page只记载文件路径
8. 当page的空间使用率低到一定程度进行page合并。每个db的kv先进先出，一般不会出现这种情况，但是因为所有的db的kv都会写到同样的page里（如果每个db各自有自己的page，会引入寻道开销），如果相连的page可以合并，会进行合并，合并后生成新的page。这里的一个约束条件是，只有相连的page才能合并，新page不能破坏page的顺序。为了这点，如果不是合并生成的page，申请时page序号不是递增的，而是有一个跨度，那么合并的新page可使用跨度间的序号。例如page100和page200合并，新page序号是201
9. 一个写线程，所有的写操作请求都会先提交，不是直接调用io，由写线程来合并请求，进行块写。在writeforce（每次写都需要刷磁盘缓存）这种策略下，提高的性能显著
10. 多个读线程，同样提交读请求，由读线程进行合并，某些读请求的数据块可能是相连或是在同一个page里，可优化成每次读较大的块，再提取
11. 支持优雅的关闭模式，拒绝新请求，等待提交的请求完成
12. key以hashmap组织在内存里，key的内存尽量保持100byte以下，如果是百万级别的数据消耗的内存比较大，可考虑适当的钝化一部分key
13. 启动时需要读完所有的page，在数据量大时比较耗时。在正常关闭时把所有的key持久化，启动时只需要解析持久化的key即可。对于一个系统来说，正常关闭的次数是远远大于非正常关闭的
14. 使用checkpoint保证数据的完整性

该文章主要起一个备忘的作用，想到啥再更新。