关于线程模型 about rudis HOT 3 OPEN

这也是我最近迫切希望解决的问题，有很多方案也在积极探索中，感谢你的提案。

我理解你的建议是降低锁的粒度，将 db 的实例锁，下放一层，到具体的 db，减少锁资源的竞争。

如果这样的话，对于不同 db 的不同数据结构上锁，似乎可以进一步提高性能，但终究都会有上锁和释放锁的性能损耗。除此之外，rudis 是否可以使用无锁编程等方式，能有更多的提升空间。

另外，我也在考虑 rwlock 是否能代替 m 锁，在读的工作上避免锁的存在，对此你有什么好的建议

from rudis.

不需要锁，网络请求通过消息传递传给某个 database 的 worker，而这个 worker 因为不会跨线程工作，所以 database 内的所有数据结构都可以是线程不安全的。这种线程模型就是 Redis 官方的线程模型，Redis 只在网络请求处理部分做了多线程，核心数据结构还是单线程的。这样做的性能是最好的，只是扩展性不够，这个问题可以通过 sharding 的方式解决。无锁数据结构并不是免费的午餐，理论上性能最好的方式就是避免任何CPU核间通讯。

from rudis.

不需要锁，网络请求通过消息传递传给某个 database 的 worker，而这个 worker 因为不会跨线程工作，所以 database 内的所有数据结构都可以是线程不安全的。这种线程模型就是 Redis 官方的线程模型，Redis 只在网络请求处理部分做了多线程，核心数据结构还是单线程的。这样做的性能是最好的，只是扩展性不够，这个问题可以通过 sharding 的方式解决。无锁数据结构并不是免费的午餐，理论上性能最好的方式就是避免任何CPU核间通讯。

再次感谢你的提案，并给出了耐心的解释，未来几个版本我们将针对代码进行进一步的调整，如果你对此也有兴趣，也欢迎你的加入 >_<

from rudis.