无聊中

真的是无聊 害我在这儿写blog 哎~~~ 不敢玩游戏 不敢看电影 不敢炒股 那就来写blog吧。。。

本人首先声明：下面写的关于flare或者其他技术的东西 我都是参照一些官方文档，网上资料和自己猜测而来，不能保证其正确性，如果有错误的地方，还望读者（肯定也很无聊，不然不会逛到我这儿）不吝赐教。

那就从我最近做的东西说起吧  最近在做一种类似于flare 的东西，flare完全兼容memcache的协议， flare用着很不稳定 而且其持久性对我们来说是没有必要的，反而大大降低了读写速度，就读写上来说我们只需要高速的memcache，但是mc有一个缺点，就是他不是真正分布式的，不能动态的增减mc进程的数量，一旦出现memcache宕机，后果将会是严重的。所以flare做了个类似mc的flared，通过index进程统一管理，可以监测到flared进程的增减，然后同步到各个proxy上，每次get|set（key|value），通过计算key的hash映射到对应的flared上去get|set，但是一旦有flared变化，以前的映射方法就可能失效，假设一种简单的求mod映射，一旦flared发生变化，这样就会极大降低命中率，所以这种求mod的动态命中方案是下策，flare跟TC有很多关系，好像是底层用了TC的结构（具体情况我也不清楚，只有去读源代码。。。），TC的动态命中方案根据其工程师的blog应该是一个叫consistent hashing的算法，这个算法能保证很高的命中率 和很少数据的重新分布，是个很好的方案。

但是consistent hashing算法却很复杂，复杂的不是他如何保证很少的数据重新分布，而是保证每个node的数据基本平衡，如果不作处理，每个node数据理论也会再平衡均线上等幅波动，但是这个方差可能较大（没实际计算过，但是有一点可以肯定，一旦每个node分布数据平衡后，新的变动总会在环上该节点出造成相当大的不平衡），不平衡的问题可以解决么，当然，第一就是加node，当node足够多，每次的最大波动都可以容忍，这当然是笨办法，还有就是用算法去维护，这个算法不会很简单，而且对平衡的结果不会特别的理想。