Kafka实战笔记
关于这份笔记，为了不影响大家的阅读体验，我只能在文章中展示部分的章节内容和核心截图
- Kafka入门
- 为什么选择Kafka
- Karka的安装、管理和配置
- Kafka的集群
- 第一个Kafka程序
afka的生产者
- Kafka的消费者
- 深入理解Kafka
- 可靠的数据传递
- Spring和Kalka的整合
- Sprinboot和Kafka的整合
- Kafka实战之削峰填谷
- 数据管道和流式处理(了解即可)
- Kafka实战之削峰填谷
- 避免链接暴露，自己工作人员，提前秒杀商品
秒杀读多写少。无需每次实时校验库存。库存预热，放到Redis，信号量控制进来秒杀的请求。
Nginx做好动静分离。静态资源 Nginx 直接返回，保证秒杀和商品详情页的动态请求才打到后端服务集群。
使用CDN网络，分担本集群压力。
服务网关识别非法攻击请求并进行拦截。
使用各种手段，将流量分担到更大宽度的时间点。比如验证码，加入购物车。
前端限流+后端限流 限制次数，限制总量，快速失败降级运行， 熔断隔离防止雪崩。
1万个商品，每个1000件秒杀。双11 所有秒杀成功的请求，进入队列，慢慢创建 订单，扣减库存即可。
高并发系统设计的三个目标：性能、可用性和可扩展性。
在提升系统性能方面我们一直关注的是系统的查询性能，比如数据库的分布式改造，各类缓存。因为大部分场景都是读多写少。
比如一个社区系统初期一定是只有少量的种子用户在生产内容，而大部分的用户都在“围观”别人在说什么。此时，整体流量较小，而写流量可能只占整体流量的百分之一，那么即使整体的QPS到了1w，写请求QPS也只是到了100，如果要对写请求做性能优化，性价比不高。
但随着业务发展，可能遇到一些存在高并发写请求场景，比如秒杀。假设你的商城策划了一期秒杀活动，活动在第五天的00:00开始，仅限前200名，那么秒杀即将开始时，后台会显示用户正在疯狂地刷新APP或者浏览器来保证自己能够尽量早的看到商品。
这时，你面对的依旧是读请求过高，那么应对的措施有哪些呢？
丢弃订单
最早期，量太大扛不住，直接前端随机reject一些，返回抢单失败，简
单粗暴，但是有效，比如10万人抢100个iPhone，只要能提前预测有大概1万以上的人参与(通过资格确认、报名等方式收集信息)，那么直接请求进来以后随机挡回去
99%的流量都没有啥问题。
优化吞吐
中间有段时间，提前准备一大批机器，服务化、分库分表搞定后端性能，让前端业务可以加一定量的机器，然后搞稳定性，依赖关系，容量规划，做弹性，提升吞吐量。
异步队列
使用可堆积的消息队列或内存消息队列。若抢单具有强顺序，则先都进队列，然后拿前N (就是库存数)个出来平滑处理，剩下都可作为失败进行批处理，甚至还可以做一个定长队列，再往里写直接提示失败。队列把并发变成串行，从而去掉了分布式锁。
内存分配
某些业务可以考虑预热，提前在每个机器节点内存分配好库存数，然后直接在内存处理库存数。
拆分扩展
对于不同类型、不同商家、不同来源的商品，部署不同的前端促销集群，
分散压力。比如，按每个整点发起秒杀，具体到每个商家，其实量就不大了。
服务降级
越重要的抢单，大家越关心自己有没有抢到，而不是特别在意订单立即处
理完，也就是说，下单占到位置比处理完成订单要更有价值。比如12306春运抢票，只要告诉用户你抢到了票，但预计1个小时后订单才会处理完，用户有这个明确预期即可。用户不会立马使用这张票，也不会在意1min还是1h内处理完。
部分方案会导致销售不足或超卖：
-
销售不足可以从抢购里加一些名单补发，也可以加一轮秒杀
-
超卖比较麻烦，所以一般会多备一点货，比如抢100个iPhone，提前准备110 个
因为用户查询的是少量的商品数据，属查询热点数据，可采用缓存将请求尽量挡在上层缓存，能被静态化的数据（比如商城里的图片和视频数据）尽量做到静态化，这就可命中CDN节点缓存，减少Web服务器的查询量和带宽负担。Web服务器比如Nginx可以直接访问分布式缓存节点，从而避免请求到达Tomcat等业务服务器。
当然，你可以加上一些限流的策略，比如对短时间之内来自某一个用户、某一个IP或者某一台设备的重复请求做丢弃处理。
通过这几种方式，请求就可以尽量挡在数据库之外了。
稍微缓解了读请求之后，00:00分秒杀活动准时开始，用户瞬间向电商系统请求生成订单，扣减库存，用户的这些写操作都是不经过缓存直达数据库的。1秒钟之内，有1万个数据库连接同时达到，系统的数据库濒临崩溃，寻找能够应对如此高并发的写请求方案迫在眉睫。这时你想到了消息队列。
理解消息队列
把消息队列看作暂时存储数据的一个容器，它是一个平衡低速系统和高速系统处理任务时间差的工具。
比如古代臣子朝见皇上陈述国家大事，等皇上决策。但大臣很多，如果同时去找皇上，皇上肯定会崩溃。后来变成臣子到午门后要原地等皇上将他们一个一个地召见进大殿商议，这就缓解皇上处理事情的压力。
可以把午门看作一个暂时容纳臣子的容器，即消息队列：
-
在Java线程池中我们就会使用一个队列来暂时存储提交的任务，等待有空闲的线程处理这些任务
-
os中断的下半部分也会使用工作队列来实现延后执行
-
实现一个RPC框架时，也会将从网络上接收到的请求写到队列里，再启动若干个工作线程来处理
那如何用消息队列解决秒杀场景下的问题呢？
总结
面试难免让人焦虑不安。经历过的人都懂的。但是如果你提前预测面试官要问你的问题并想出得体的回答方式，就会容易很多。
此外，都说“面试造火箭，工作拧螺丝”，那对于准备面试的朋友，你只需懂一个字：刷！
给我刷刷刷刷，使劲儿刷刷刷刷刷！今天既是来谈面试的，那就必须得来整点面试真题，这不花了我整28天，做了份“Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法等”
且除了单纯的刷题，也得需准备一本【JAVA进阶核心知识手册】：JVM、JAVA集合、JAVA多线程并发、JAVA基础、Spring 原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB、Cassandra、设计模式、负载均衡、数据库、一致性算法、JAVA算法、数据结构、加密算法、分布式缓存、Hadoop、Spark、Storm、YARN、机器学习、云计算，用来查漏补缺最好不过。
[外链图片转存中…(img-rvn9hlGw-1715654281250)]
扫一扫
2003
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
