从支持异步并发编程的Web后端框架到数据存储服务的分布式一致性哈希路由

 异步并发框架应该可以解决web后端开发的IO性能问题，比如node、go？、tornado、openresty？，剩下的就是数据存储如何做切分和LB了，当然，可以考虑使用内存数据库，这样数据存储不需要管持久化

关键的持久化仍然可以使用mysql，要么做主从分离，要么做jdbc前端转发，但是mysql的水平切分仍然是个技术活（对于业务逻辑复杂的情况）

假如不考虑索引需求，所有的索引全部走lucene/es，不考虑连接/分布式连接，而是增加冗余存储；那么核心存储可以只需要关心如何做LB/高级切分，每个物理存储可以自己用B树实现一个简单点的

但是不论是哪一种LB/数据切分，理论上某个物理分块节点都可能过载，这个时候就需要进一步的分裂，不幸的是，在要求服务可用性、一致性、多副本等等的前提下，这个分裂过程不容易做好

当然可以使用DHT：假设一个经过水平切分后的节点物理存储仍然过载，此时需要调整整个存储网络的拓扑/容量，然后相当于做下面的逻辑操作：将此节点从网络中detach分离，将节点上的数据以最小单位重新put回去

说起来好像很简单，但是做起来复杂：detach过载节点的前提是网络先扩容，扩容之后原有的DHT机制可能不再适用，那么如何保证这个扩容不需要调整现有的存储节点呢？一般使用Hash到虚拟节点，虚拟节点再映射到物理节点，这就是所谓的一致性hash。问题是这个其实并不能保证前面的“调整过程”是IO代价最小的