电商
高并发三种处理方式
- 系统拆分
- 缓存
- MQ
做项目的时候，如果我们有个变量，我们需要在上下文一直传递下去，那这个时候怎么去弄呢？
- 可以用Threadlocal，或者是它的子类，这样的话主线程跟子线程之间可以通信，也能相互传递。
你有了解过它的原理吗？
- 原理其实就是一个空间换时间的这样的概念嘛，他本身是有两层Map，嵌套在里头的。
秒杀减库存
- 扣件库存就是先发送一个半消息，然后使用lua(撸啊)脚本加Redis,在接入层直接扣件库存Redis库存， 然后异步写数据库达到数据一致性，如果出现问题的话回滚数据，就是去扫表，然后达到一个最终的一致性。
类似电商的项目，什么支付功能，还有什么秒杀功能，就是有没有遇到什么问题，后来又是怎么解决的？
-
遇到的问题是吧，那这个也是很普遍，就是我们会遇到这个大量的这个用户访问到我们这个服务器上面的这些情况，那站在服务器层面上的，这个资源都是有限的嘛， 那我们只能用这些有限的资源去处理这些大量用户的请求，而且还要求我们效率还要快嘛，那我的处理方案就是把这个流量呢， 分担到一个更大宽度的一个时间点嘛，比如说我们加一点这个验证码功能，加入购物车这些功能啊，都可以实现一个分流嘛， 然后前端限流，后端也要限流，就是我们限制他次数，限制它的总量啊，然后快速的一个失败降级运行啊，还要我们的熔断隔离防止这个雪崩， 就比如说我们一万个商品嘛，然后每个是1000件去秒杀，那考虑到这些所有的一个秒杀成功的请求呢，其实我们是要去进入队列啊，就是要去写一个队列， 慢慢去创建我们的订单，再去扣减我们的这个库存嘛，那库存那边也要去做一个预热嘛，就放到我们的redis，然后信号量去控制我们的秒杀请求， 然后我们的nginx去做好我们的一个动静分离，静态资源啊，我们的nginx要直接返回，要保证我们的秒杀和我们的这个商品详情页的一个动态请求， 请求后才可以打开我们这么个后端服务集群，差不多就这样。
-
像这种系统我们肯定还要考虑它的安全嘛，就是我们要避免一些恶意攻击嘛，然后我们也要避免我们的一个链接暴露嘛，就是怕我们的一个工作人员嘛， 知道链接了他们去提前去秒杀这个商品所以我们要给这个秒杀链接，要去加密，然后我们肯定也会遇到很多这种脚本的恶意请求，然后我们也要去做做这些相应的一个拦截， 就是我们这个服务网关识别，它的这么一个非法的攻击请求，然后去进行我们的一个拦截，那在这种场景下，就是短时间内的这个数据库它的一个访问量会非常高， 它的一个读写量也会很高，所以我们也应该去分库分表，然后去拓展更多的数据库。然后去应对我们的这么高的一个写流量嘛，然后在后台要去启动若干个这个队列， 去处理我们这个程序，消费MQ中的一个消息嘛，再去执行我们的一个校验库存啊，然后还要我们这些下单啊，这样的。
怎么完善这个系统？
- 其实我那个的时候就去考虑了，就是使用消息队列去降低业务系统嘛，还有就是数据系统的一个直接耦合度嘛， 然后我们还想要去抵挡我们的这么个高并发的写流量，比如说做一些缓存啊，做一些日志啊，做一些监控之类的东西， 当然还有我们的负载均衡啊，我们的动态路由啊，去使用那个阻塞队列嘛，使用阻塞队列线程池的方式啊， 让这些拥护先去拿到秒杀资格，然后我们再通过计算，去返回给客服嘛，那那会呢我还一直想的就是我们的异步处理， 其实是提升我们这个系统性能的一个神器，但是呢，我们需要分清楚这个同步的一个流程，和异步的一个流程，他们这个的一个边界， 就是这里面的消息啊，他存在的一些会丢失的一些风险啊，所以其实当时也是考虑到的说去怎么去保证这些消息能够一定能够达到。