redis的几项修改

 

最近的空闲时间都在抠redis的源码，强大并最大限度节约内存的数据类型是里面的亮点。

看完后有点想法，在上面做点个人感觉能起正向作用的修改。

 

1. 基于redis的原生事件框架支持多线程处理访问，类似于memcached的处理手法。在多核处理器上能有多大的性能提升还要看测试结果。虽然说多线程访问引入锁和增加系统复杂度，但对于性能的提升还是抱乐观态度的。
2. 额外提供2个数据类型，一个是ziplist的改进版，实现更紧凑的内存结构。一个是uintset，在某些场景，都是uint，uintset针对uint作优化，主要也是节省内存，但可能会损失轻微的性能。
3. 移除vm的相关代码，虽然作者也说vm的代码在以后的版本废弃，但2.4.2还是存在的，因为要在上面做改动，这部分代码实在是非常碍事。对于vm，初步有个想法，换一个思路，大多数的处理方法都是把冷数据自己管理，写到磁盘。在这里，把一部份冷的value再分配到一系列完整的内存块（大于等于4k），剩下的就交给操作系统了，热数据不会阻碍冷value被交换到磁盘区。这样就不用自己做io。这个想法的可行性还要进一步验证。
4. 客户端支持localcache。之前iteye有张帖子是说localcache的http://www.iteye.com/topic/1117582，感觉localcache这个想法挺有意思的，但是对于这种监听通知的处理方法不太认同。初步的方案是localcache的数据支持超时时间，在超时前，都是返回本地的数据，超时后再远程cacheserver获取，当然也支持强制远程。然后重新计算超时。这种方案的好处是简单，对于cacheserver没有额外要求，并且滞后时间可控。这个功能对于允许数据更新滞后的场景还是有价值的，例如在一些展现给用户的场景，在几秒钟内都是本地cache，如果是高频率访问，带来的提升还是很可观的。如果cacheserver还支持数据version，在读多写少的情况下，连数据传输都省了。

突然发现，redis2.4.3 release了，之前的改动都是基于2.4.2的，还要去抠一下2.4.3的变动。。。。