twemproxy选择哪个redis库

twemproxy选择哪个redis库

打个jstack看，最底下醒目的deadlock。一看，jedis干的。然后看代码，发现维护集群meta信息的类里一堆synchronized方法和一堆非synchronized方法中间共用了一个读写锁，一个线程把WriteLock锁住后若干行会试图执行一个synchronized方法，另一个线程执行别的synchronized方法时会在某行试图获取ReadLock，然后就喜闻乐见的死锁了，这简直太……了。更……的是其实那个类里所有的synchronized都是多余的，而最新的代码里我发现他们已经把synchronized去掉了，理由是为了提升性能。于是开issue跟他们说了下旧的代码会死锁，建议他们尽快把最新代码发布新版，然后有人说虽然这是bug，但只要timeout别设成无穷，死锁的代码会自动超时释放的，可我们明明把timeout设的很短好不好……总之懒得理论这些事情了，改了bug之后死锁问题没了，但翻译被吓尿了，切回memcache，也因为事多人少，直到现在也没功夫重新换回redis……后来就没遇到过问题了。于是开始总结吧。首先先说前提：twemproxy作为老牌的redis集群方案，他确实在特定历史阶段实现了他的价值，但他肯定是不如现在的codis，具体codis哪好可以看很多文章介绍。然后是官方cluster的优点，其实真的只有一个，就是没有proxy转发之后极限性能好，但绝大多数场景真的不重要。非说第二个优点就是他是官方的，只要redis还在维护，redis cluster被弃坑的概率就比较低，项目会持续有人维护，而第三方的方案理论上确实开发者弃坑的概率会比redis官方要大。不过只要第三方的方案真正成熟到一定程度，就算弃坑不更新大家也还是可以用。就像redis如果截止2.8.x就不开发了，大家照样会用一样。