Cool带你学治理体系-3

数据分片

上述的数据冗余可以通过数据的复制来进行解决，但是数据的扩张需要通过数据的分片来进行解决（如果在关系型数据库是分表）。

何为数据分片（segment，fragment， shard， partition），就是按照一定的规则，将数据集划分成相互独立、正交的数据子集，然后将数据子集分布到不同的节点上。

HDFS ， mongoDB 的sharding 模式也基本是基于这种分片的模式去实现，我们在设计分片主要考虑到的点是：

• 做数据分片，如何将数据映射到节点
• 数据分片的特征值，即按照数据中的哪一个属性（字段）来分片
• 数据分片的元数据的管理，如何保证元数据服务器的高性能、高可用，如果是一组服务器，如何保证强一致性

柔性化/异步化

异步化

在每一次调用，时间越长存在超时的风险就越大，逻辑越复杂执行的步骤越多存在失败的风险也就越大，如果在业务允许的情况下，用户调用只给用户必须要的结果，而不是需要同步的结果可以放在另外的地方异步去操作，这就减少了超时的风险也把复杂业务进行拆分减低复杂度。当然异步化的好处是非常多，例如削封解耦等等，这里只是从可用的角度出发。异步化大致有这三种的实现方式：

• 服务端接收到请求后，创建新的线程处理业务逻辑，服务端先回应答给客户端

• 服务端接收到请求后，服务端先回应答给客户端，再继续处理业务逻辑

• 服务端接收到请求后，服务端把信息保存在消息队列或者数据库，回应答给客户端，服务端业务处理进程再从消息队列或者数据库上读取信息处理业务逻辑

柔性化

什么是柔性化，想象一个场景，我们的系统会给每个下单的用户增加他们下单金额对应的积分，当一个用户下单完毕后，我们给他增加积分的服务出现了问题，这个时候，我们是要取消掉这个订单还是先让订单通过，积分的问题通过重新或者报警来处理呢？

所谓的柔性化，就是在我们业务中允许的情况下，做不到给予用户百分百可用的通过降级的手段给到用户尽可能多的服务，而不是非得每次都交出去要么100分或0分的答卷。

怎么去做柔性化，更多其实是对业务的理解和判断，柔性化更多是一种思维，需要对业务场景有深入的了解。

在电商订单的场景中，下单，扣库存，支付是一定要执行的步骤，如果失败则订单失败，但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性