盘口数据频繁变化
星球水友提问:盘口数据频繁变化,如何做缓存与推送,如何降低数据库压力? 并没有做过相关的业务,结合自己的架构经验,说说自己的思路和想法,希望对大家有启示。 一、业务抽象
二、潜在技术折衷,降低服务器压力。 2. 业务的实时性如何满足? 盘口业务,对数据实时性的要求较高,服务端可以通过TCP长连接推送,保证消息的实时性。 由于推送量级巨大,可以独立推送集群,专门实施推送。推送集群独立化之后,增加推送服务器数量,就可以线性提升推送能力。图所示,假设有100W用户接收实时推送:
3. 推送服务最大的瓶颈是,如何将一条消息,最快的推送给与之连接的10W个客户端?
画外音:对应水友提到的,如果量不大,可以成交一笔推送一笔。
画外音:对应水友提到的,如果消息量巨大,批量推送是很好的方法。 4. 数据量,写入量,扩展性如何满足?何,根据本业务的数据量与写入量,单库应该是没有问题的。 5. 复杂的业务逻辑操作,如何满足? 本业务的写入量不大,但读取量很大,肯定不能每个读取请求都sum/group by/order by,这样数据库肯定扛不住。 水友已经想到了,可以用缓存来降低数据库的压力,但担心“随着时间的推移,这个偏差势必会慢慢放大”。 关于缓存的一致性的放大,可以这么搞:
如此一来,复杂业务逻辑的计算,每秒钟只会有一次。 带来的问题是,一秒内可能有很多流水写入数据库,但不会实时的反应到缓存里,用户最差情况下,会读到一秒前的盘口数据。 无论如何,这是一个性能与一致性的设计折衷。 上面的所有方案,都是基于在线客户量级巨大,推送消息巨大的前提下,采用推送方案。很多时候,工程师都会妄加猜测,把问题想得很复杂,把方案搞得很复杂。
如果在线用户量很小,用户能够接受的盘口时延较长(例如5s),完全可 (编辑:应用网_丽江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |