得物社区计数系统设计与实现

社区业务有非常多的数字统计场景，基础的场景主要有以下这些：,其中部分场景还会有很多细分情况，例如内容相关的统计还会有以下场景：,这样排列组合出来的最终结果就有很多了，比如需要查询用户发布的图文内容数、用户点赞的视频内容数等等，且这些数字一般都需要能够支持高度精确性、高性能查询和批量查询等能力。,具体案例可参考下列图示：,,   (图1)        , ,(图2) ,  , (图3),结合当前社区的业务现状、体量以及考虑中长期体量增长的规划，我们也调研了业内比较常见的一些实现方案，最终敲定通过维护一套计数中心的服务，由计数中心服务统一管理社区的数字统计的方式，整体情况大致如下：,,该场景下计数中心内部主要干三件事，主要包括数据获取、数据处理、数据持久化。,数据的获取一般有两种方式，通过接口或通过MQ的方式，既然是平台服务更希望对业务没什么侵入性，因此我们目前采用的主要是MQ的方式。,使用MQ的情况下也有两种方案可取，一种是业务服务根据事件触发MQ消息，需要业务服务先保证业务数据已经持久化且需要生产端保证消息投递无丢失，另一种则是直接通过订阅业务数据表binlog的方式，这种方式可以保证业务数据已经持久化，目前得物已有DTS(数据订阅平台)，使用起来也比较方便且可保证消息投递不丢失，因此我们目前更多的是采用第二种方案。,数据获取到后我们做一些格基础校验，验证是否存在我们必要的一些字段是否完整，同时需要验证数据处理的幂等性防止数据重复消费等，通过消息ID和业务唯一ID做幂等，然后把每行业务数据的各字段格式化成变更前和变更后俩个值且可以区分出是新增还是更新(binlog消息体就是这样因此更加方便)，之后就可以进入数据处理阶段。,拿到通过校验和格式化后的数据，根据对应的事件和规则来判断当前变更数据具体要做什么操作，我们通过具体的案例来看会更直观，如：,场景1. 用户A关注用户B,场景2. 用户A发布的图文内容状态由正常变为删除,3.1.3 数据持久化,持久化部分主要分为两块，一是DB持久化，二是对于缓存的更新。社区的数字统计场景主要有以下两种情况：,又因为我们通过MQ消费数据是无序的，极端情况下可能会出现先减再加的情况从而导致负数的出现，因此存储层的字段需要支持有符号的数据，保证最终计算的结果是正确的即可。DB层持久完成后再直接操作缓存变更数字并延长有效期，若缓存不存在则不处理等待读场景有需要时再处理。,读场景整体逻辑比较简洁，就是先查缓存，缓存不存在就查询DB再写入缓存即可，可批量跨场景查询，需要注意对负数情况的处理。,计数中心是业内比较常见的做法，相对于老方案能够降低各个业务对于复杂计数场景的维护成本，提升迭代效率和系统稳定性，独立出来后在出现异常时业务也可做短时间降级，从而降低对核心业务的影响面。 ,目前社区已有多个场景接入计数中心，结合当前的现状及未来的可能性，考虑后续主要优化方向主要有：,