摘要： Redis经常因为各种大key/hot key的问题未及时处理导致服务器的性能下降： 什么是大key 大key的具体表现是：redis的key对应的value很大，占用Redis的空间比较大，本质上是大Value的问题。 1.对于String，value超过10M，（数据值太大） 2.set、lis 阅读全文

摘要： 告警中发现接口响应时间从200ms变为12秒，CPU达到90% 问题产生的原因竟然是：分页查询导致的。 这里产生的原因竟然是：MYSQ深度分页的典型问题，--数据越往后，速度越让人抓狂。 本质原因就是：传统的分页机制，在数据洪流下的失效。 limit 100000 ，10，这样的查询会让数据库像逐页 阅读全文

摘要： 大表数据如何删除 思考： 1.一次行删除可能存在的问题 2.删除条件是否加索引 3.删除方案 4.删除后一些后置处理 一次性删除存在的问题 1.1锁表卡死业务： 因为删除会长时间锁表，（尤其是大事务），其他查询和写入操作被阻塞。 影响：业务接口超时，页面卡死。 删除一千万条数据，耗时间是2个小时，在 阅读全文

摘要： 问题：当消费速度跟不上服务端的发送速度的时候，消息就会堆积 问题 1：业务系统上下游的能力不匹配，造成堆积。 2.业务系统对消息的实时性要求高，短暂的堆积也无法接受。 阶段1：拉去消息： 1.客户端通过轮询从broker里面获取消息，放到本地缓存队列，这个阶段一般不会有性能问题 2.客户端把消息给业 阅读全文

摘要： 排行榜的思考： 遇到排行榜，大家就想到数据库的orderby 比如：微信运动 这个实现是没有问题的，如果表的数据量少的话，推荐使用 大量数据的排行榜：如果在亿级别的数据，同时很多并发的情况下，怎么办？ 使用上述的方法：磁盘扛不住，排序算不动，并发撑不起来： 当数据量较大：并且实时更新&&频繁查询的时 阅读全文

摘要： 对于亿级别的表：如何扩字段，不是简简单单的ALTER...TABLE这么简单呢。 锁表风险，页分裂，索引性能衰减少，每一个问题都可能引发线上的事故，如何在不影响业务的情况，只是简单的配置，就可以实现字段的动态扩展？ 对于大表不能随意的加字段 在加字段过程中，锁表问题，后续随着字段的和数据的不断增多， 阅读全文

摘要： HTTP请求：servlet3.0之前是一个线程从头处理到尾 servlet3.0之后，提供了异步处理； 可以选择容器分配给请求的线程与相关资源，减轻系统负担，从而增加吞吐量 其实服务端的异步还是同步处理对于客户端而言是不可见的，不会因为使用了异步接口的返回就不一样了，另外对于：单个请求而言，使用异 阅读全文

摘要： websocket应用场景 在实际的生活中我们经常会遇到：服务端会主动推送给客户端数据的业务场景，比如数据大屏的实时数据，比如消息中心的未读消息，比如聊天功能。 常用的服务端向客户端推送数据的实现方案，有哪几种？ 1.轮询 2.webSocket 3.SSE 轮询： 轮询的实际也是客户端向服务端发送 阅读全文

摘要： 后端并发问题，或者重复下单问题，可以采取：一锁二判三更新： 一锁：表示先获取锁，保证同一个时间只有一个操作能执行 二判：检查数据的状态是否符合预期，防止脏更新。 三更新：确认无误后执行更新操作。 比如：扣库存的场景： 为什么要这么做呢？ 1.两个用户同时给同一个商品下单，而商品仅剩最后一件库存，如果 阅读全文

摘要： limit问题： 分页查询是常用的场景之一，但也是通常最容易出问题的地方，比如下边的SQL “select * from tab where type='1'and name ='abc' orderby created_date limit 1000,10” 但是当limit 1000变为limi 阅读全文