qinwenjng120的博客

第 42~52 位 ：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群/机房的节点，这样就可以表示 32 个 IDC，每个 IDC 下可以有32 台机器。如果是订单号，竞对可以直接知道我们一天的单量。在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在算法生成的 ID 中加入业务类型信息。以服务的方式部署（可以不依赖数据库等第三方系统），稳定性更高，生成 ID 的性能也非常高的。

促销活动并不是电商系统的核心业务，但是各个电商系统一般都有促销活动，而且形式多种多样。因此，在设计促销系统时，最为核心的关注点是要如何在尽量少的影响主体业务的前提下，尽可能保持促销规则的灵活性。优惠券code字段： 用户领取优惠券时， 针对用户领取优惠券记录，可以生成个coupon_code字段，在有些促销场景下，这个code就很有用。比如小米的F码，输入用户领取优惠券时生成的coupon_code, 就可以购买指定的商品并使用优惠啦。3. 查询用户可领券的优惠券。2. 用户领取优惠券。

本文的作用：学习秒杀场景下压测计划，具体执行暂未执行。

2. 参加的人越多越好。

用户下订单是电商项目中最核心业务， 订单服务中几个重要的问题，需要特别关注。

⿊产⽤户总能想出五花⼋⻔的抢购⽅式，有借助物理⼯具，像“⾦⼿指”这种帮忙点击⼿机抢购按钮的；有通过第三⽅软件，按时准点帮忙触发App内的抢购按钮的；还有的是通过抓取并分析抢购的相关接⼝，然后⾃⼰通过程序来模拟抢购过程的。针对第一种，在风控时做处理。针对第二种：Token机制， 让接口直接保持依赖关系，从而限制黑产直接调用接口。header_filter_by_lua_block ： 响应头部或cookie处理。

所以考虑将增加redis从节点个数。秒杀系统为提交读库存的性能，将redis从节点和nginx节点部署在一起的， 如果升级成redis集群， nginx读哪个从节点呢？-》考虑将nginx也水平扩展。（nginx可以扩容原因：商品详情页的静态页面发布到OpenResty上， 那么就可以考虑将不同商品的页面发布到不同的openResty上）

先看下普通web项目架构： （Nginx : 反向代理、负载均衡，一般是运维部分做生产搭建的时候配置好）秒杀架构设计：和普通架构区别：核⼼设计是对巨⼤的瞬间流量进⾏层层错峰。错峰1：页面静态化。将包含浏览者信息的动态数据和不包含的静态数据进行区分。错峰2：秒杀前答题。⽬的是防⽌机器刷单，以及错开⽤户的下单时⻓。错峰3：Redis扣减库存。快速扣减库存， 扣减库存完通知nginx.错峰4：Nginx快速通知秒杀结束。错峰5：MQ进行流量消峰错峰6：引⼊ MQ 进⾏下单服务异步化—场完整的秒杀活动的⼤概流程是这

4. ⼤批量删除数据，还要注意下，执⾏删除语句后，最好能停顿⼀⼩会，因为删除后肯定会牵涉到⼤量的B+树⻚⾯分裂和合并，这个时候MySQL的本身的负载就不⼩了，停顿⼀⼩会，可以让MySQL的负载更加均衡。以Mysql存储的订单数据为例，随着业务的发展，数据量越来越大，对一些历史归档数据的查询，如果直接从DB查询就不太合适，比如"2021年订单"等等。由于B+树的有序性，这些ID相近的记录，在磁盘的物理⽂件上，⼤致也是存放在⼀起的，这样删除效率会⽐较⾼，也便于MySQL回收⻚。2. 将数据写入新的存储系统。

针对电商系统，在遇到大流量时，必须要考虑如何保障系统的稳定运行，常用的手段：限流，降级，拒绝服务。

在微服务架构中，完成某一个业务功能可能需要横跨多个服务，操作多个数据库。这就涉及到到了分布式事务。需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据操作，要么全部成功，要么全部失败。本质上来说，2PC（二阶段提交）TCC可靠消息（MQ）基于 Seata AT 实现。

无论任何业务系统，无非就是两个操作：写和读。在海量数据和高并发的场景下，写和读就会成为系统性能的瓶颈。场景1：广告扣费系统。广告通常要么按浏览付费，要么按点击付费（业界叫作 CPC或 CPM)。具体来说，就是广告主在广告平台开通一个账号，充一笔钱进去，然后投放自己的广告。C端用户看到了这个广告后，可能点击一次扣一块钱(CPC)；或者浏览这个广告，浏览1000次扣10块(CPM)。扣款要尽可能实时，如果慢扣了， 就可能造成广告主没有钱了，但是广告仍在播放。

支付实际上是一个风险非常大的业务，真正能够自主开发第三方支付产品的企业非常少。因此大部分企业都需要接入第三方支付产品，通过他们形成自己的支付能力。比较有名的第三方支付产品有支付宝、云闪付、和包支付、翼支付等。支付宝提供了两个重要的服务开放平台，对外开放自己的核心支付能力。第三方企业都可以通过这两个服务开放平台接入支付宝，借助支付宝开发自己的支付场景。2. 开发者登录支付宝开放平台后，进入控制台，需要在控制台创建对应的应用appId.还有各种产品签约流程。下面以支付宝为例，描述接入支付产品的大致流程。

大促等场景，并发请求数量的基数过大，即便只有很小比率的请求直接访问数据库其绝对数量也仍然不小，还是会存在系统雪崩的风险。构建Redis集群后，由于集群可以水平扩容，因此只要集群足够大，理论上支持海量并发就不是问题。所以可将将Redis当做数据库使用，将所有数据都缓存到Redis。解决缓存不命中的问题。在缓存一致性章节讲到过，为了保证DB和缓存的数据一致性，DB变更时，需要删除Redis缓存。思考：Redis缓存了这么多的DB数据，如何保证数据一致性呢？1. 分布式事务保证DB和缓存一致性。

如果说要对你的项目进行优化，最先想到的就是使用缓存。说到缓存，最先想到Redis， 可是缓存可不仅仅只有Redis。缓存有哪些类型？如果保存缓存一致性？是本文要回答的问题。

1. 闭包原则（CCP）: 当改变一个微服务时，所有依赖这个微服务的组件的其他服务，都不需要修改。2. 服务自治、接口隔离：尽量消除对其他服务的依赖。3. 持续演进：一边做产品功能迭代，一边完成服务拆分。4. 服务接口的定义要具备可扩展性：比如定义接口参数，最好将参数封装成类。5. 避免环形依赖与双向依赖：这种情况说明功能边界没有划分清楚， 或者通用的能力没有下沉。