面试实战题-网上问题处理

实战案例	秒杀	秒杀步骤 1、发送获取验证码请求，后台生成验证码并写入redis 2用户填写验证码，发送检验验证码请求，后台校验成功后创建并返回秒杀专属路径 3、发送秒杀请求，发送商品id和path，后台验证path，验证是否已经秒杀成功（防止重复下单），并预减库存（内存操作） 4、发送mq消息 5、监听mq秒杀消息，校验库存，判断是否已经秒杀成功 6、减库存，创建订单，将秒杀成功信息写入redis 7、如果减库存失败，将秒杀失败信息写入redis 8、发送秒杀结果查询请求 如何防止流量过大导致的性能问题 1、拦截器中判断流量大小，如果超过预定流量，则直接返回失败 2、在活动开始前，将商品库存信息和无库存标志位缓存起来 3、活动开始前将商品详情等页面html缓存起来。 4、活动开始时先让用户输入验证码 5、让事务在mysql端执行，使用存储过程而不是spring声明式事务。屏蔽网络延迟和GC的影响。	简单秒杀功能实现思路-CSDN博客
	杭州项目实战	作业空间提升并发性能	Spring Cloud + Docker + K8S 项目优化_springcloud tomcat优化-CSDN博客
	天津项目实战	盗油车，kafka消息堆积	大货车燃油盗窃案件管控应用详述-CSDN博客
	面试技巧	准备项目描述的说辞、准备好亮点和难点	当你收到面试通知后，通过如下的准备可以大大提升面试成功率
	局部变量引用线程池，导致内存泄漏	ThreadPoolExecutor  ->   Worker   ->  Thread    由于存在这样的引用关系，并且 Thread 作为 GC Root ，所以无法被回收  full gc频繁：一天40次，dump后使用mat分析，发现线程对象4万多个，检查代码发现是在异步任务创建时局部方法内新建线程池和线程。导致线程对象回收不掉而内存泄漏。 解决方法：讲线程池对象作为全局变量进行复用。	https://www.cnblogs.com/Shock-W/p/9835469.html#commentform
	CPU飙升	cpu飙升这类案件，一般来说有几个对象嫌疑重大： ● 嫌犯A：内存泄漏，导致大量full GC ● 嫌犯B：宿主机cpu超卖 ● 嫌犯C：代码存在死循环 问题现象 从monitor上看到，这台机器cpu占用达到300%多，而GC一览并没有出现full GC，只是出现了一些常规的YGC。再观察堆内存使用情况，也属正常，先排出了oom的嫌疑。 前面通过top命令拿到java应用的pid是2143，通过top -Hp pid 命令，查看进程内的线程情况： top -Hp 2143 不看不知道，一看吓一跳，犯罪现场触目惊心！前几个线程都占用了大量cpu，并且占用cpu时间最长的一个线程（tid=32421)，已经存活了5个多小时。 继续进行追查，这货到底在干啥？ printf "%x" 32421 -- 拿到十六进制 jstack pid | grep tid -- 查看线程情况 原来这个线程在HashMap.getEntry()这，线程状态显示是RUNNABLE，说明并没有出现死锁(Blocked)，而是不停run了5个多小时，看来凶犯已经找到：死循环非他莫属了! 问题原因： 多线程同时put时，有一定几率导致环链表产生，导致get方法进入无限循环，进而导致了cpu飙高。	一次应用 CPU 飙高的血案排查过程
	kafka消息堆积/一直rebalance	问题现象： 1.其他订阅的消费者组均能够正常消费，只有本应用出现堆积 2.日志中发现，本应用的两个消费者实例都在消费 3.日志中还发现，搜索同一车牌号和时间，有很多的消费日志 直接原因： 正常情况下每一批次间隔5分钟最多大概150条消息。 这次问题出现的原因为Broker宕机，导致堆积的消息过多，每一批达到500条消息，导致poll之后消费的时间过长（700s），超过max.poll.interval.ms（默认300s）。导致Coordinator（运行在broker上的group Coordinator）以为客户端失效进行Rebalance，因此连接到另外一个消费者实例，然而另外一个也出现超时，又进行Rebalance...如此循环，才出现了两个消费者都进行消费，并且一直重复消费。 找到问题的所在就比较好解决了，加大超时时间（800s） 其他方法如减少拉取条数(200条，允许短时间堆积)，如果消息量比较大的话还可以增加消费线程等也可以。	Kafka线上消息堆积问题 - 简书  记一次线上Kafka消息堆积踩坑总结_kafka消费数据一会儿就变慢了-CSDN博客 记一次线上kafka一直rebalance故障 - 简书
	kafka  broker和consumer client版本为什么要一致	生产遇到一个问题，一个kafka broker集群升级到1.0.0后，consumer 客户端版本还是老的0.10.0.1，这样没法使用zero copy特性了导致有大量数据写入后kafka broker OOM了。请问我如果把consumer 客户端版本升级到1.0.0后，他连接的另一个老的broker集群（还是0.10.0.1版本）是否还能使用zero copy？kafka版本是向下兼容的吗，还是consumer和broker版本必须一致才能使用zero copy这样的特性。	38 | 调优Kafka，你做到了吗？-Kafka核心技术与实战-极客时间
	MetaSpace空间设置过小导致的full gc		记一次线上FULL GC排查经历
	高并发系统设计	高并发系统的几大方向 1.请求数据尽量少，从而减少cpu消耗 2.访问路径尽量短，减少节点消耗 3.强依赖尽量少，减少加载时间 4.不要有单点，要有备份 5.减少额外请求，减少加载时间 为了系统的高可用，我们需要B计划，为了使系统仍然可用，我们准备了降级、限流、拒绝服务三件法宝。 1、结算页的所有操作设置轻量级 主流程的任何操作都会将数据保存的缓存中，秒杀系统的结算页所有操作都尽可能的轻量级，将数据保存到隐藏域，提交是通过post请求调提交服务。 2、非关键性业务异步化 非关键性业务是指即使异步调用失败，也不会影响用户正常下单的系统，对于非关键性业务考虑异步化。 3、Java服务端的并发保护 为了保护秒杀系统后端的关键服务，需要进行并发限制的处理。比如调风控的服务，当每个tomcat实例并发连接数超过10个就放弃请求风控服务等类似的并发保护措施。	01 | 设计秒杀系统时应该注意的5个架构原则-如何设计一个秒杀系统-极客时间
	线上问题定位，除了打日志之外还要什么方式