从订单中心开始,聊“多KEY”类业务数据库水平切分架构实践

作者/分享人:58沈剑
“架构师之路”公众号作者,58到家高级总监,技术委员会主席。前百度高工,58同城高架,技委主席。

有一类“多KEY”特征的业务,典型代表是“订单中心”,业务查询维度会覆盖order_id/buyer_id/seller_id,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对订单中心业务进行水平切分是本章的重点:

  1. “多KEY”类业务的特点与场景。
  2. “多KEY”类业务如何进行水平切分核心指导思想。
  3. “多KEY”类业务水平切分后遇到的潜在问题(最典型的问题->通过order_id来切分,buyer_id/seller_id上的查询怎么办?)。
  4. “多KEY”类业务水平切分最佳实践。

实录提要:

  • 两种方案的综合方案,能具体说下这个方案的具体玩法吗?
  • 单日 5000 万的 Log 可以设计在 MySQL 里吗?
  • 若是已在线使用的业务系统中的“多 key ”表应该如何着手进行拆分?
  • 多库的分页和数量 count 统计,如何做是每个库进行统计和查询?
  • 用客户端分库分表与服务器端分库分表各有什么好处,怎么选型?
  • 最终一致性有什么好的中间件软件吗?算法自己实现起来要花很多时间吗?
已有210人预订
预订达标
文章出炉
交流日期
     
04月18日
08月21日
08月29日 20:30
查看文章评论/提问
思考的犀牛
两种方案的综合方案,能具体说下这个方案的具体玩法吗?一句话,实际上解决不了大家的实际问题,还是想看大佬在实际业务中如何解决这个问题的,谢谢!
listen
实用又好理解,喜欢沈大大的风格,基因法给了另外一种实践参考,其他方法都已用过,效果很不错,谢谢,继续支持
马里奥的马里奥
在oid后加上基因,这个的确很赞,可以直接定位到库。我有看到京东针对订单的分库依据就是先根据oid分库,然后异步监听log,将数据同步到以userid为分库依据的库中。
小鱼
请问,如果是已在线使用的业务系统中的“多key”表应该如何着手进行拆分,操作过程有哪些注意点?
小鱼
存在多key关系表的前后台系统分离后,如果前端写多读少,后台读多写少,有哪些方法可以保持他们之间数据同步且数据一致(可以允许较少时间延时)
你可能还喜欢
Service Mesh 在华为公有云的实践
田晓亮
从零开始,搭建 AI 音箱 Alexa 语音服务
Mike
Web 安全恩仇录:再谈逻辑漏洞
肖志华
如何用 Vue 实现前端权限控制(路由权限 + 视图权限 + 请求权限)
雅X共赏
智能增长:如何用大数据和人工智能实现业务体量的增长
蒋凡
有关 Mock 的是是非非
思考的犀牛
微信扫描登录