ASIO,无锁,高并发,高可靠, 统一,网络架构,抗DOS,低端4核心服务器CPU 每秒87万QPS ECHO

wlmqgzm

其实, 我现在就在想, 数据库中万恶的锁,  其实, 目前的编程新技术已经可以把内存数据库中的锁彻底抛弃了,

但是市场中好像还没有一款这样的产品, 不知道是什么原因. 也许是我孤陋寡闻吧.  

我的理解, 无锁的内存数据库在普通4核心上并发可以轻松过百万, 应该瓶颈在网络层, 内存层没有锁, 就基本没有消耗.

考虑自己来做一个这样的产品吧, 网络层的代码调优完毕, 我就开始做无锁的内存数据库.   

只要实现了无锁的内存数据库, 那么内存数据库的并发量就会随着CPU内核的增加而线性增加,

现在的技术路线上有好多种办法, 真的有好多种, 我自己都知道不少, 都可以实现无锁.

初步计划, 我先测试2个最简单的技术路线,

1是内存分区, 然后按核分配内存, 每个核管理自己的区域, 无冲突, 但是有可能单核心的压力过大, 不平衡.  然后就是每个核心有一个队列, 这个队列是lock_free的,
这个技术路线, 是最简单的技术路线, 用软件让数据对核心固定下来, cache也比较固定, 说白了, 这个技术路线是内核操作无阻塞,单线程, 外围解决冲突的问题.
外围使用lock-free解决问题.      

2是读写冲突校验法, 利用Intel的SSE指令实现,  理论上可以达到内存带宽, 无瓶颈. 可以保证, 在任何情况下, 无论多少个并发读写同一片内存区域, 至少有一个线程可以成功, 无锁无阻塞无冲突, 全部内存任意存取, 任意访问, 很随意.   这个方案, 还需要做代码, 才能测试, 明天就能给出评测结果.

二种技术路线, 技术上都不复杂, 代码也没有多少, 初步估计, 大约静下心来, 做一个简单的数据库核心,  

我准备明天开始先做测试代码, 对技术路线进行性能分析评估,   然后根据测试报告做最后的产品,  

想一想无锁的数据库, 是多么的美好啊.  想一想都觉得自己以前怎么就没有用过这样的无锁的数据库 产品呢?????

无锁的世界是多么的美好.

呵呵呵呵呵呵.   

windoze

回复 81# wlmqgzm

然而当你需要强一致性的保障时，几乎所有的lock free技术都并没有什么卵用……

wlmqgzm

回复 82# windoze

刚搜集资料, 最新情况:

两种方案:
方案一, 按照Boost的介绍, 是可以保证只有一个操作能够并发, 也就保证了强一致性.
这个方案最终读写在核心态都是单线程, 靠外围lock-free协调解决冲突, 核心读写均是单并发. 这个比拼的是lock-free的协调能力.
现在, 只有这个方案是内存数据库的可选方案之一.

方案二, 有人曾经做过, 目前了解到的情况是:
代码写操作单线程, 可以提供写一致性, 同时并发读, 读并发没有数量限制, SSE提供校验方法, 读要校验, 校验失败要重新读, 来解决读写数据冲突, 特点是高并发读, 单并发写.
主要是在一个小代码中做cache服务的, 一个是当时只选择hash表, 而且是一次性分配内存, 这样地址都固定, 读写都不涉及hash表结构的变化, hash表只做了一层, 无链表结构.
有重复直接覆盖, 所以,只保留最后的数据.
这个方案, 现在看来只是cache版, 无法担任数据库的技术解决方案.

windoze

回复 83# wlmqgzm

lock free只能保证数据的“完整性”，但没法保证数据的“一致性”，尤其是当你需要transaction这种东西的时候，最好情况下你能得到MVCC这个级别的保障，但很多场合下这是远远不够的，而且即便是这个级别的保障也复杂的能干掉一票脑细胞。

你可以试试用lock free技术实现一个支持transaction的主从表数据结构，然后就会发现做出来的东西未必比直接用lock的版本快…………

wlmqgzm

回复 84# windoze

其实, 我的lock-free方案已经初步成型了, 技术可以做的, 因为所有的操作核心是单线程的, 就是读队列,执行队列中的命令, 外围队列上使用了lock-free, 就是一个lock-free队列,没有其他代码,

现在就看明天测试了, 看核心代码效率.      上条回复,有修改.否决了方案二.

windoze

回复 85# wlmqgzm

方案1这种所有load都在一个thread里，和加锁版的性能未必会有很大区别，而且由于request queue是一个lock free queue，这种queue不能block，所以当一个请求正在处理的时候其它所有I/O thread都在忙循环，相当的烧CPU。

方案2中你说的这种hash table，肯定是open addressing hash table对不，但这种hash table最大的问题就是尺寸上限不能变(不能rehash)而且key不能删，所以除非你你一下预留好大一块，否则跑着跑着就塞满了，这个时候除了报错退出没有任何办法可以挽救……

wlmqgzm

回复 86# windoze


方案二, 这个hash不太大,  这个hash内容是可以覆盖的, hash也可以冲突, 老数据会被新数据覆盖.

由于读struct中有校验码,并且校验码在最后, 读完struct就校验下,校验错就重读, 这样避免了struct写一半的情况

另外hash不用删, 办法是超时, 就是struct里面有时间变量, 超时无效, 就ok

这个是一个高性能无锁cache解决方案, 挺好的, 没有什么技术上的问题, 没有冲突, 该考虑的地方都有考虑.

其实, 仔细想来, 这个架构是目前的Memcache的理想替代品, 预计可以把Memcache的性能有一个大幅度的提高. 我再搜集点资料, 看先做哪个产品....

从代码数量和技术难度上看, 应该是cache好做一点, 好吧下周决定, 先从哪一个代码开始.

wlmqgzm

回复 86# windoze



方案一, 所有load都在N个thread里, N=逻辑CPU的数量, 因此, 冲突概率要小N倍,  先把数据内存按CPU均分了, 每个CPU一个队列, 每个CPU只管自己一小部分,

lock free queue 的性能很好的, 比一般队列好, 设置一个大的队列,例如64k,  并且核心执行队列速度很快, 几乎就没有忙循环了,再有就usleep, 因为那么大的队列都满了,核心要多工作一会, 才能完成队列任务, 所以, 不存在烧CPU的问题, 因为usleep了.
   

windoze

回复 87# wlmqgzm

覆盖是没问题的，hash冲突也是正常现象，但“不能删”这一点限制了它的用途，我之前写的Argos就因为这个必须要定期重建hash table，不大不小是个麻烦。

我个人觉得钻“无锁内存数据库”这个牛角尖价值不是太大，毕竟已经有一堆现成的性能不错的东西可以用，搞搞集群可能价值更高一些。
比如用gossip/raft/paxos做metadata同步的集群，可以随时扩充新节点，还可以在一定程度上保持数据一致性，毕竟这种东西现有的都不太好使。

Riak拿erlang写的，想改改都要头疼半天；Cassandra性能就是个渣；HBase读性能还说得过去但写性能比Cassandra还要渣；CouchDB的集群就是个玩笑；CouchBase的集群是一个比CouchDB还要搞笑的玩笑；ElasticSearch这东西集群也跟没集群差不多；MongoDB都集群了居然还有单点；MySQL……谁提MySQL来着…………

windoze

回复 88# wlmqgzm

另外你知道为什么加了usleep就不烧CPU了吗？因为OS kernel把调usleep的thread给切了，不过这么一来和加锁就木有区别鸟……