Old Wang的博客

随着业务发展速度越来越快，数据的增长也呈现倍数级别增长，数据库的压力，对于查询和写入等所有操作，都依赖于主库，其实有一些对于时效性要求不高的场景，无需使用主库查询，可以使用从库来分摊主库的压力，提升数据库集群整体的吞吐量。

从零开始设计开发优惠券系统（四）概述本章节主要讲优惠券链路的黄金流程，喜闻乐见的领券。领券是营销过程中用户参与度非常高的一种行为，领用的券可以作为现金或者打折的方式直接抵扣支付现金，实打实的能够得到优惠，在促活和拉新场景下作为常见的手段来使用。在成本cover住的情况下，能够实现平台和用户的双赢。核心关键点1.限制流量1.1 限制刷子流量设计领券的流程最先考虑的一定是限制流量，领券是直接能面对消费者的，也就是，任何一个人如果有基本的技术，都可以通过反编译或者解析调用链接来进行刷券请求，也就是

背景mongo主库现在分片较多，十几个集合表，共计上百亿数据，查询的量比较大，cpu和内存的压力也越来越大，为了更好的利用好mongo，决定使用mongo从库进行常规的查询，减轻主库的负担。介绍基本配置说明mongo读写规则在mongo中的概念为 Read Preference,可以理解为读偏好，或者读配置。官方文档：https://docs.mongodb.com/manual/core/read-preference/下图解释 了一些策略模式读配置模式描述primar

背景最近在搞数据迁移，之前存储的介质为mongo，集团层面在推动mongo下线，所以迁移到mySql是主流趋势，mongo目前共6分片，总数大概40亿左右，mySql承接的话，设计为32个库，每个库128个表。数据库的分片，中间件团队已经做了，我们需要处理的是路由到表这块的处理前置官方资料https://shardingsphere.apache.org/document/ 选择5.0.0版本进行阅读使用Spring boot 能很快结束开发，使用Spring mvc实属无奈，但是旧系统升级重构

本篇文章主要讲解下优惠券系统是如何做到高并发、高可用的