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

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给切了，不过这么一来和加锁就木有区别鸟……

wlmqgzm

回复 90# windoze

这种模型中, usleep发生的概率接近零, 内存读写处理很快的,  如果真的有任务队列把6.5万或者更高的记录都塞满的话, usleep一下, 休息1个毫秒, 不算什么事情.
太偶然了, 我估计上亿次读写事件, 也不会发生一次, 可以在代码中加Log, 实测, 如果发生概率非常小的话, 就跟没有这个事情一样.


   

wlmqgzm

回复 89# windoze

其实, 集群的思路也有, 后面先看单机的代码和测试情况, 如果做的效果好的话, 就接着做集群的代码.

集群思路, 我觉得还是受限于单机, 取决于单机性能的, 还有有一小部分数据, 需要超高的性能, 作为metrix的母体, 母体负责指出每部分数据在哪个单台服务器上,  
母体服务器的数量不多, 属于核心层, 我希望是1套双机HA, (平常的办法有N套mother从机分担查询, cache有超时, 数据各种更新都有一个中间状态, 总体要协调等待, 复杂, 不是自己希望的, ),
做所有服务器的母体, 如果有超高性能的代码, 那么这个母体就可以带大量的子机, 实现起来就非常轻松.

其实, 我希望一个简洁的环境, 宁可多分几个集群来解决, 每个集群处理一部分数据, 每个集群带一堆服务器,   

hellioncu

LZ自己就是在玩概率编程，埋地雷，说他还不承认：
“由于读struct中有校验码,并且校验码在最后, 读完struct就校验下,校验错就重读, 这样避免了struct写一半的情况”

wlmqgzm

回复 93# hellioncu
LZ自己就是在玩概率编程，埋地雷，说他还不承认：
“由于读struct中有校验码,并且校验码在最后, 读完struct就校验下,校验错就重读, 这样避免了struct写一半的情况”

这里面没有地雷, , 你确实很厉害, 这么细节的东西都被你给发现了, 呵呵呵呵
对, 这个有一定概率, 单校验的话, 大约20亿分之一的概率, 未能检测, 双校验的话, 大约400亿亿分之一的概率未能检测,  
校验码的技术已经被公开过一次,

里面还有一个细节, 我没有说, 这里面没有地雷, 概率为零, 好吧, 我保守了一点, 还有核心的技术没有坦白:......................删掉了
这个也许涉及大数据下高并发的关键核心技术的商业秘密,  请各位保密.


   

hellioncu

wlmqgzm 发表于 2015-10-30 10:30
回复 93# hellioncu
LZ自己就是在玩概率编程，埋地雷，说他还不承认：
“由于读struct中有校验码,并且校 ...

正确的措施只需一种即可，何必要多重保险增加开销？

BTW：你考虑 memory barrier 了么？

wlmqgzm

回复 95# hellioncu

采用多重保险, 可能也是对新架构不放心, 多一层可以让BOSS安心吧, 然后就可以马上在关键核心上使用了,
另外, SSE指令效率高, 就一次读的开销,  
原始架构不是我做的, 我是路人甲. 太具体也不了解.
只知道后续没有人关注这个东西, 因为就一层cache, 校验码也一直没有去掉.
可能 库定型了吧.

memory barrier 会拖累全部核心的运行速度, 在这种cache代码架构中, 没有使用的必要, 加了反而拖累运行效率.
   
   

hellioncu

wlmqgzm 发表于 2015-10-30 11:33
回复 95# hellioncu

采用多重保险, 可能也是对新架构不放心, 多一层可以让BOSS安心吧, 然后就可以马上在 ...

无锁但不考虑memory barrier，让人怎么说你好呢。
无锁不是你想象的那么简单，坑很多。。。