关于ssdb的一点想法

最近有一些应用打算用ssdb来做，但是心里又不是很放心ssdb的持久化方案，于是四处查资料，看源码，翻来翻去，终于大概心里有谱了。ssdb目前的所有写操作都是没有调用levelDB的同步写的，如果服务器遭遇意外断电，损失的数据量可能大于30s内的写入量，另外，由于ssdb的多主服务模式同步是异步的，可用性也不能达到理想的状态。要解决这个问题，目前我有三个想法：

       第一个是自己写一个proxy放在ssdb前面，一来可以实现一些简单逻辑的数据分区，二来可以把一些写操作同步到多个ssdb实例上。但是这个首先要多写一个网络层，比较麻烦，而且还要写php客户端的api，把简单的事情复杂化了，而且可能带来一些别的问题，感觉不太划算，当然优点是完全独立，不用改别人的代码。

       第二个想法，就是模仿redis实现，在ssdb里开一个线程按配置每隔一段时间（比如1s）， 自动调用fsync同步一次到磁盘。这个办法应该不难，当然不知道这样想是不是太简单，可以稍微实现出来做一下测试看看能不能满足我们的需求。

       第三个想法，就是给ssdb添加一组同步写版本的api，这个要改的地方就相对多一点，主要是很多命令都需要接口，代码上应该不复杂。缺点就是这些新的api恐怕就没法兼容redis的接口，不过既然redis没有类似的接口，用redis的人应该也没有这方面的需求。

       其实我个人比较偏向第三个想法，因为从本质上来说，是否需要磁盘同步还是由业务本身决定的，既然业务有关键数据也有不太关键的数据，那么就应该让实现业务的人来选择是否同步，这样才能达到使用中的最佳平衡，我想leveldb的开发者应该也是这样想的。第二个和第三个想法可以同时实现，互为补充，这样可以取得一些实际应用中所需要的折衷。

     如果过几天有时间，可以fork一份ssdb的源码，先从第二个想法开始试试看能不能行。