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

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，让人怎么说你好呢。
无锁不是你想象的那么简单，坑很多。。。

windoze

回复 96# wlmqgzm

1. Lock free的各种实现都必须用到memory barrier，否则你根本做不出来
2. SSE指令不是原子操作，不能保证数的完整性和一致性
3. 在这种场合下checksum不能就地检测数据错误，除非你把整块数据copy出来自己再算一遍

所以你能做的就是：
要么把所有数据操作集中在1个thread里，就像redis那样，当然你可以用多个thread处理I/O
要么就使用race-free的数据结构保存数据，比如lock-free hash table或者干脆加把锁
这两个方案会导致所有的数据写操作都实际变成单线程，对你的系统吞吐量是有影响的。
想要降低这种影响，你只能切分数据，比如把一个hash table切成若干个，每个core/thread专门负责一个，这样可以降低冲突概率。
类似的手段就是集群，干脆把数据切分到多台机器上去，也一样可以降低冲突概率。

wlmqgzm

回复 97# hellioncu


    因为只是类似memcache的东西, 允许老数据存在, 允许cache数据与主库数据不一致. 数据结构中有time, 过期无效.

其实只是一个memcache同样功能的东西, 就是性能更好一点.  memcache有的缺点, 它都有, 这个不是颠覆性的新东西.

wlmqgzm

回复 98# windoze

1. Lock free的各种实现都必须用到memory barrier，否则你根本做不出来
答复:  这个很简单, 因为没有调用那么低层次的代码, 直接使用Boost库, 库里面应该考虑了这些, 就是直接使用Boost::lock-free::queue,  就三行代码.construct, push, pop

2. SSE指令不是原子操作，不能保证数的完整性和一致性
答复:  SSE指令就是一个校验的作用, 在前面给其他人的回复中, 有具体的说明.

3. 在这种场合下checksum不能就地检测数据错误，除非你把整块数据copy出来自己再算一遍
答复:   读, 是Memcpy, 先一次性读到本地栈的struct中, 然后再处理.     写, 是先在本地栈操作完毕后, 一次性写到hash表中, Memcpy.

对于方案一, 做内存数据库, 存在大量单线程的情况, 就是分摊了数据, 这个没有什么好办法, 就是用单线程解决问题.  但是数据切分多块以后, 提高了总体对外的表现.
对于方案二, 就是只做类似memcache的东西, 可以实现单线程写, 多线程读, 提供比目前memcache性能更好的替代方案. 写是只能单线程, 没有什么好办法.读性能会高一些.

基本上2套方案, 对应的是两套不同的产品, 整体的技术架构, 各实现的主要技术难点, 基本上应该在讨论中都有具体的解决方案,
我觉得cache的总体设计框架基本就这样定型了, 只是实现细节还有不少, 难度上讲, cache的实现要简单一些.

内存数据库无论大小都是非常多的人力资源堆出来的东西, 除非走捷径, 我的思路是要拿MYSQL挡一下, 减少代码量, 具体思路, 以后再讨论.