专注网站开发有做美食的视频网站么

专注网站开发,有做美食的视频网站么,长沙代理记账,天津网站优化方案从券商SDK消息到达#xff0c;开始运行到下单#xff0c;再到定位#xff08;下单请求#xff09;整个过程非常冗余#xff0c;以下仅先探索前面队列驱动及优化部分。我们如下绘制流程图#xff1a;QuoteReader(行情读取器/对应每个券商) -- QuoteService(行情服务)-…从券商SDK消息到达开始运行到下单再到定位下单请求整个过程非常冗余以下仅先探索前面队列驱动及优化部分。我们如下绘制流程图QuoteReader(行情读取器/对应每个券商) -- QuoteService(行情服务)-- RouteTable(关注股票路由表) ,如果股票不感兴趣就不处理丢弃数据包否则加入_QuoteHandler 到 handler_ptrs行情处理器列表行情服务器会创建多个线程并且绑定线程到对应的核心上面分派股票到 QuoteHandler 是通过模数法。公式(next_index_ 1) % handler_ptrs_.size()其实你知道的这个是错误的正确的做法命名是(next_index_) % handler_ptrs_.size()来获得派发的上下文索引。并且这里还存在致命的问题因为这种队列会存在多核利用效率低的问题如某个股票或一组能 mod 在这个索引上的 QuoteHandler我们设想一下这种条件是非常容易达成的那么 QuoteHandler 会直接导致致命的性能洪塞问题打爆驱动这个 QuoteHandler 的线程而且这个线程还是个绑核的被洪水冲压的负担是极重的。这个设计简直非常不专业正确的做法是像我们创建一个事件循环队列就像 boost::asio、ev_event/uv_event 事件队列循环一样可以同时多个线程去驱动它但我们实现一个 strand 串行化的机制。首先要知道把它实现成无锁队列并确保多个线程可以进行驱动确保所有的线程都可以有效的执行工作是很有意义跟价值的并且这并不难以实现它。我们设计一个无锁化的 strand 串行队列结合 SpinLock自选锁可以以非常低廉的成本来完成高性能的队列数据交换传输。而且在我的新设想当中已经不会再存在前面这么多冗余架构这是没有意义的额外增加性能开销成本从一个队列传给另外一个队列然后多重队列开销要知道这东西最好的就是一个全局并发队列是性能最好的解决方案即便是面对高频也是毫无问题因为自选锁的开销很低这里的队列我们直接用 std::list 就可以但我们需要自定义 std::allocator 内存分配器CAS原子队列只适合多个线程写单个线程读取的情况SPSC队列只适合一个线程写一个线程读但我们需要的是多线程读、多线程写的高性能队列那么上面这样的队列就可以。这种队列是一个大结构行情数据过来券商SDK行情消息是分派到不同线程回调过来的它可以直接触发我们的队列管理逻辑这部分因为大家都知道合理的设计根本不存在什么性能开销它不可能一秒钟塞入一个亿的数据我们结合CAS自旋锁来实现这样一个管理结构。message_on_order、message_on_trade、message_on_snap 这三类消息我们不能保证消息的顺序性但我们可以同个类型的消息是连续性的所以这部分我们如果额外增加一层队列在循环这个队列的开销是比较大的但我们设计成这样开销只会比这个更低更好。即自旋锁 {主队列 [股票ID]-post( 消息指针 );} // 临界区尾部主队列 std::unordered_map股票ID(UINT32类型).....无锁串行队列-------------------------------------------------------------看上面这样的结构我们可以得知是绝对不可能产生什么多核性能问题的。但这里还没完我们需要实现一个 多线程驱动器上下文类似 ev_event、boost::asio::io_context 调度器这样的玩意那么要怎么来高性能多线程驱动这个主队列容器呢首先我们不能弱智的轮询法这个股票ID数量可能高达三千只这样直接轮训代价过于昂贵我们假设现在为主队列驱动四个线程绑定四个CPU核心意味着同时可以四个核心都在处理数据。那么这里可以通过一个取巧的办法。我们可以创建一个跟主队列相同长度的链表结构即拥有相同长度的链表节点但是我们不要去分配更多的也不要用了就释放因为这个场景是程序跑在实盘环境下要退出直接关闭程序直接对象池化计数因为交易所下午三点收盘那么什么时候分配 NODE每次发现主队列没有指定股票ID的串行队列时那么就可以认为是需要分配新的串行队列、跟对应的NODE这个NODE其实可以直接在串行队列当中分配弄成私有变量跟主队列这边管理代码声明为友元好类它们本来就是一个整体。只要队列里面添加上了数据那么就在串行队列上面增加一个原子计数或者手动管理内存屏障来同步计数。这个计数的目的是用来表示信号量的即当前队列有事件就需要被执行处理直到这个信号没有就像是共享指针一样是一个调度执行所需要的引用计数。只要我们插入消息等效于一个事件信息时这个计数就要添加1如果这个计数从0到1若为原子处理是可以获得之前的原有值的我们判断如果为0那么就意味着这个需要插入到主队列当中的调度链表中而不是每次enqueuepost都是无条件插入这是错误不对的。这样子主队列的多线程那边驱动器是不是就知道了哪些要去遍历驱动但这里有一个很有意思的并发处理设计细节每个线程一次只能争用一次主队列CAS自旋锁并把链表头部的元素弹出同时检查如果本次减少了一个计数是否等于0如果为0则表示这个不需要添加到链表的尾部注意非0需要添加到链表尾部。每个线程通过这样的方式从链表中循环获取主队列当中的事件处理对象。实际上这里分了两个步骤。串行队列的事件是用来告诉主队列我能不能被调用避免主队列那边线程遍历三千个股票减少性能损耗只去处理需要执行逻辑的地方。-------------串行队列这边实现更有意思post 仍然是需要实现为自旋线程安全的但会增加一个CAS当前执行线程标质0表示没有现成在执行非0线程ID表示这个线程它正在执行流程因为我们需要多核串化流程让在空间时序上面要保持顺序的但必须被多个线程多个CPU核心同时驱动处理又要尽力保证没有性能损耗尽可能减少队列造成的性能损耗。上面提到了单核单线程在特定情况下会导致延迟增大因为突然来了大量消息被派发到这个线程给洪塞堵住了导致了大量的延迟及计算负担没有合理利用硬件资源。但需要注意必须确保cas锁的最小持有粒度即在我们获得当前需要处理的串行队列指针后不要在上锁了而是需要释放出来资源让其它线程可以去争用下一个串行队列。好的上述流程跑完我们就可以执行串行队列的 do_events 函数这个函数只需要两个分支部分。一个通过线程 thread_local 预存的当前线程ID来跟CAS原子变量进行 原子比较交换而不进行自旋如果失败表示当前队列正在被其它人争用它就不要去处理直接跳出否则就进入开始处理当前串行队列当中插入的消息并派发到不同的消息处理函数当中首先这里需要明确一点它自己串行队列有一个写的原子锁CAS自旋这个是为了跟上面 Enqueue(post) 函数成对临界区代码保护的所以你只能弹出队列上锁并且弹出一个就得释放处理完毕后重新争用写原子锁尝试弹出如果失败就把当前标记CAS线程的原子变量设置为0即可这样我们就可以尽可能的利用更多的CPU让整个系统调度负载更均衡效率更好更棒更强并且我们可以结合C 17有栈协程尽力让这四个线程不会让出所有CPU给操作系统当然这四个线程会被绑定CPU核心亲和性并且线程优先级最高进程改成RT实时模式最大化独占资源实现更为理想的高频高并发高时空线性处理。注意这里是现有队列派发驱动跟新型队列派发思路的一种设想。