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

yulihua49

wlmqgzm 发表于 2015-10-28 18:42
回复 2# windoze

最终修改代码, 想办法 把BOOST ASIO 的IO_SERVICE队列中的锁也去掉了,  呵呵呵呵呵

客户端服务器都在一个机器上吗？
我怎么感觉跨百兆网有点够呛。

wlmqgzm

回复 78# yulihua49

百兆网肯定不行, 至少得千兆网络, 否则软件处理能力够, 但是瓶颈都在网络上,  目前大约400Mbit/s,  还在做代码中, 先本机测试吧, 简单方便, 以后再详细测.

现在 Transfer rate:  37141.80 [Kbytes/sec] received,  

wlmqgzm

http://bbs.chinaunix.net/thread-4082130-1-2.html
千万级并发实现的秘密：内核不是解决方案，而是问题所在！

摘要：C10K问题让我们意识到：当并发连接达到10K时，选择不同的解决方案，笔记本性能可能会超过16核服务器。对于C10K问题，我们或绕过，或克服；然而随着并发逐渐增多，在这个后10K的时代里，你是否有想过如何去克服C10M。

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好做一点, 好吧下周决定, 先从哪一个代码开始.