摘要：开篇金币积分商城下称商城是众多内的一个产品，随着使用的用户越来越多，商城对于用户留存的提升，扮演着重要的角色做为提高用户黏性的核心产品，在拥有很好用户体验的同时，也必须存在着一个高效稳定的系统。分析上述两点，得到结论按用户进行分库分表。
开篇
分库分表金币（积分）商城（下称“商城”）是众多App内的一个产品，随着App使用的用户越来越多，商城对于用户留存的提升，扮演着重要的角色；做为提高用户黏性的核心产品，在拥有很好用户体验的同时，也必须存在着一个高效、稳定的系统。
商城，是一个基于虚拟货币（下称“金币”）进行运营的产品，也就意味着，我们需要给用户发放金币，用于用户兑换各种奖品。我们需要详细记录用户金币的收支情况，并提供给用户查询。在redis、memcache盛行的时代，构建一个几十万QPS的只读系统并不复杂，需要做到：无状态服务+多级缓存，并且能够进行水平扩展，应该就差不多了。而商城需要记录每秒十万的用户行为，需要的是每秒数十万（这里翻倍了）的数据读写（insert&update)操作，这种量级是无法在单实例数据上完成的，那么该如何分库分表。
分库分表原则Tip 1 . 在做设计时，首先要明确3个事情
业务场景，不要空谈设计，场景是什么
目标，系统需要做到的目标是什么
分析上述两点，得到什么结论
那么，对于用户行为数据的场景是：1.用户A查询自己的所有金币记录（不能查别人的），2.查看商城内金币数量分布情况。对于第二个场景可以直接通过大数据进行统计分析（不进行详细解读）。对于第一个场景，系统需要做到的目标是：用户A只进行一次查询，就可以得到所有数据（不考虑分页场景）。分析上述两点，得到结论：按用户id进行分库分表。（分析过程有些磨叽了，哈哈，忍着）
原则明确后，能够开始进行分库分表吗？不能。需要进一步确认，如何分？分多少？扩容成本？对于数据库扩容，我们选择以2的N次幂进行扩容，这种方式的好处是，进行扩容时，只需要将数据copy一份就可以，上层应用增加数据库节点，无需考虑数据迁移问题（可靠性高），不好的地方是，会产生脏数据，这个问题并没太多影响，按照扩容后规则，删除即可。对于分表，我们将金币记录在每个库中拆成5份。
Tip 2 .为什么要进行分库分表
服务器资源（cpu、磁盘、内存、IO）遇到瓶颈
数据量变大，数据操作（crud）开销变大
部署图如下：
数据编号=uid%4，表编号=uid%5
算法流程图如下：
目前业内对分库实现方案有两种
客户端分库分表，在客户端完成分库分表操作，直接链接数据库。
中间件（例如：cobar），客户端链接中间件，由中间件完成分库分表操作。
这两种方案各有利弊，客户端分库分表由于直连数据库，所以性能比使用中间件要高。而使用中间件，能够很好的将分库分表操作与客户端隔离，数据调整对上层透明，便于统一管理。
订单id生成策略为什么要关注id生成策略？全局唯一，全局有序，业务隔离，不容易被猜到等等，这些都不是关键。重点讨论下，如何让看似无意义的id，对系统后续扩展带来意义。
Java领域著名的唯一id应该算是uuid了，不过uuid太长，而且包含字母，不适合做为订单id。通过调研，我们借鉴了Twitter的Snowflake算法来实现，算法思想是在64位长整型数字中，存储node编号，并且有序，同时支持并发。
为了便于订单数据后期扩展，我们有必要在订单id生成时，就将其做好分库分表准备（虽然目前订单量不多）
其中serverid，占2位，最大支持2^2台服务器（0-3），dbid占6位，最大支持2^6个数据库，其他以此类推。
最终一致性订单数据除了用户维度查询外，还有通过商品维度来查询的场景，例如：按照商品，进行订单发货。为了解决这个问题，我们对应的策略是，将订单数据进行冗余，并按照商品维度进行存储。方案虽然简单，但是保持两个订单库数据的一致性是一件很麻烦的事情。
显然单机数据库事务是无法解决的（数据不在同一个数据库中），所以要保证数据一致性，需要引入强一致性的分布式事务，这个方案先不谈实现成本问题，就凭其超低的效率，这是我们无法接收的。所以引入异步数据同步，来实现数据的最终一致性。当然，异步同步数据也会带来数据不一致（消息总线丢消息，嘿嘿），所以我们又引入了实时监控服务，实时计算数据差异，并进行一致性同步。
流程图如下：
数据库高可用Tip 3 . 类似这种存在多个纬度的数据存储问题，都可以采用这种方案来解决
这是个经典的议题了，我们在这个方案上，并无创新，用几张图来简单说明下。
如何让商城在大流量下存活？这是一个类似抢购或者秒杀场景如何应对的问题，对于这个问题在@沈剑 的《秒杀系统优化思路》中已经写的很清晰了，那么，我再补充一下。
中心思路路仍然是”逐层消耗流量“，应用层面对大流量情况下，很有可能自身难保，还没来得及拦截流量，自身就已经OOM了。那么该如何优化这个方案？见下图：
在ngx层进行优化，有两个方案：
达到应用层最大处理能力时，Hold住流量，让请求排队，逐步施放流量到应用层。
达到应用层最大处理能力时，抛弃多余流量。
我们采用的第二个方案。视频课程
==【完】==
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/67103.html
摘要：可水平扩展，可以添加更多服务器来扩展您的数据库需要管理员是否开发人员和管理员都可以使用适用场景会计师事务所和银行，以及需要具有清晰架构的结构化数据的其他公司。 今天的主题是从MongoDB漫谈数据库，在日常的项目中，我们一般都是使用的mysql作为数据库，但是一旦有问题，又常常会听到类似要不换成MongoDB试试的声音，因此就让我们这些小白来随便聊聊数据库 什么是数据库 我们就用最简单...
阅读 2075·2021-11-22 09:34
阅读 1703·2021-09-22 15:22
阅读 1803·2019-08-29 15:05
阅读 1924·2019-08-26 10:43
阅读 3252·2019-08-26 10:26
阅读 715·2019-08-23 18:29
阅读 3426·2019-08-23 16:42
阅读 1849·2019-08-23 14:46
