none
求教OLTP高并发数据库设计 RRS feed

  • 常规讨论

  • 感谢进来朋友查阅此帖:

    工作流的数据表,数据表里存储的是工作流里每个节点的任务数据,流程节点间的关系比较复杂,非1对1的关系,还有错综复杂的优先级需求

    常规思路是一张工作流任务表,有流程节点的字段,节点状态字段等。

    任务表数据量上限10条。

    500个人,每人平均1秒3次完成领取任务->工作->提交任务整个过程。(非高峰时期,这个过程是全天都是这样的频率)

    常规思路情况是领取时,把领取到的记录标记状态为:已领取,一次select优先级排序查找最需要领取的,一次update标记数据的状态为:已领取。

    然后工作完成后提交任务,一次update所提交任务的状态为:已完成,一次update下一节点的任务为:可领取。

    测算一下500*3,每秒1500次领取任务到提交任务的过程,每次过程完成需要经历一次select和2次update。

    也就是说单张数据表每秒1500次select和3000次update。

    在这个过程中还会时不时的有新的流程任务会新增至该表,而且考虑到不断新增的流程任务还需要根据固定规则删除或转存已彻底完成的流程任务。

    这么设计并发问题好像Hold不住,请教各位大神可有什么好的思路解决?

    2014年12月18日 10:01

全部回复

  • 之前做过一个高并发的短信系统

    对单表的插入、查询、update要求大于1000条每秒。

    最后的思路是,将持久化和队列分离。

    队列在内存中维护,对于结果在数据库做持久化。

    另外对数据库也做了分表,后期也加了一些列日志表,避免数据丢失和服务重启保证数据不丢失。(如果使用MSMQ,这个就不要自己做)

    总的一个思路,就是增加环节、使单个业务处理的时间延长,但是可吞吐量可以类似集群的方式扩展。最终实现支持高并发。


    family as water

    2014年12月19日 1:41
  • 估计没有人能给你固定答案,高性能的系统都是慢慢迭代出来的,不是问出来的,经过时间考验

    虽然后台都是用的数据库,但是不同的应用程序,例如楼上stoneZ大侠做的短信系统 所用的技术和架构都不一样

    他的情况并不一定适合你

    还有就是

    “单张数据表每秒1500次select和3000次update”

    这个就需要经过测试了

    2014年12月20日 1:01
  • 列日志表,避免数据丢失和服务重启保证数据不丢失?

    这个没看懂,

    如果内存里进行队列岂不是就服务器宕机数据就没了,哪怕是MemcacheD,Redis等内存数据库的方案也会导致数据丢失的。

    另外我的这个情况是工作流,存在流程节点相关性问题,每次业务操作都会存在Update问题,或者必须做标记,才能保证后面的流程节点进入可开始状态。

    使单个业务处理的时间延长这点在性能要求上不通过,性能要求必须高,这个开会讨论过了。

    另外内存做队列,内存数据库等方案也开过会了,被否了,存在数据丢失风险

    分库分表方案已经做好了,目前唯一剩下的就是如何设计数据库来提升单库单表的并发能力。

    2014年12月22日 8:12
  • 貌似工作流就是串行的,将串行 强硬 变为并行 ,弄巧反拙
    2014年12月22日 8:50
  • 1.内存数据库 都有防止重启丢失数据的解决方案的 这个可以多了解一下。

    2.单个业务处理时间延长,不是说很长。你可以想我们对于代码进行逻辑分层一样,这个会带来效率降低(有限),但是给应用带来可维护性,和扩展性。

    3.分库目前看来是你最好的方案了(前面的方案需要对于使用的产品有很深入的了解)。

    你可以简单的设想一下,单台服务器可以处理200每秒,那么使用10+台就能处理2000个请求了。而对于应用来说如何设计一个中间层,对应用统一数据库访问,才是最复杂的。 taobao这类有着海量用户的系统,至少有100+以上的分库。目前再大的用户除以100,都不会太会超过千万,自然能够保证性能需求。


    family as water


    • 已编辑 Stone Z 2014年12月23日 1:45
    2014年12月23日 1:44
  •  拆表分库的方案已经做了,内存数据库的方案经过几次大会已经彻底否了。。。

    我主要是想讨论下如何设计提升单库的最大并发性能啊!

    2014年12月23日 2:41