爱陪小樱桃

导航

 

2025年9月21日

摘要: mysql数据的自增加的id(int)类型,超过范围: 数据自增加ID,为int类型,超过范围,就插入数据库失败; 怎么解决? 由于数据比较大, 1.第一个简单粗暴:把int变为(BIGINT)不用迁移数据库,但是这种会全程锁表。按照数据量评估 2.分布式ID,需要重新设计表,需要把数据迁移到新表, 阅读全文
posted @ 2025-09-21 21:17 cherry小樱桃 阅读(6) 评论(0) 推荐(0)
 

2025年9月3日

摘要: 每秒钟100万次的商品搜索,响应时间在200ms内。同时应对商品数量超过10亿。你怎么考虑 1.不能使用mysql的like: 商品数量超过10亿不能使用mysq的like,like无法触发索引“%keywords”无法利用索引,触发全表扫描,10亿数量单词查询可能耗时是:数秒。 2.不支持分词搜索 阅读全文
posted @ 2025-09-03 21:45 cherry小樱桃 阅读(21) 评论(0) 推荐(0)
 
摘要: null的场景问题 用户是“null”字符串 如果:代码判断if (username==null),抛出异常, 和代码里面username="null",是不一样的,后者是用户取名就是“null”,不是Java里面的null,不是SQL里面NULL,而是一个字符串,日志打印的时候显示:当前用户是:n 阅读全文
posted @ 2025-09-03 21:19 cherry小樱桃 阅读(11) 评论(0) 推荐(0)
 

2025年8月26日

摘要: 系统阻塞场景问题 1.前端无限制的请求 2.大文件上传,导出 3.线程池耗尽 4.内存泄漏,溢出 5.代码逻辑错误,比如死循环。 6.数据库连接池沾满 7.数据库慢查询(索引不生效,在刷脏数据) 8.下游接口无响应,但是又没有设置超时时间。 9.缓存,消息队列故障。 前端无限制的并发请求 导致线程池 阅读全文
posted @ 2025-08-26 22:32 cherry小樱桃 阅读(13) 评论(0) 推荐(0)
 

2025年8月21日

摘要: 在我们的开发过程中,都会用到分布式ID,比如:分布式锁,幂等,数据库的唯一主键,都需要分布式ID。 1.数据库的自增ID: 利用数据库的auto_increment.生成唯一ID。 优点:简单,ID有序,索引效率高。 缺点:单点故障,扩展性差(分库分表困难) 适用场景:单机或者简单的主从架构系统。 阅读全文
posted @ 2025-08-21 22:22 cherry小樱桃 阅读(6) 评论(0) 推荐(0)
 

2025年8月20日

摘要: Redis经常因为各种大key/hot key的问题未及时处理导致服务器的性能下降: 什么是大key 大key的具体表现是:redis的key对应的value很大,占用Redis的空间比较大,本质上是大Value的问题。 1.对于String,value超过10M,(数据值太大) 2.set、lis 阅读全文
posted @ 2025-08-20 20:45 cherry小樱桃 阅读(45) 评论(0) 推荐(0)
 

2025年8月19日

摘要: 告警中发现接口响应时间从200ms变为12秒,CPU达到90% 问题产生的原因竟然是:分页查询导致的。 这里产生的原因竟然是:MYSQ深度分页的典型问题,--数据越往后,速度越让人抓狂。 本质原因就是:传统的分页机制,在数据洪流下的失效。 limit 100000 ,10,这样的查询会让数据库像逐页 阅读全文
posted @ 2025-08-19 20:56 cherry小樱桃 阅读(6) 评论(0) 推荐(0)
 

2025年8月17日

摘要: 大表数据如何删除 思考: 1.一次行删除可能存在的问题 2.删除条件是否加索引 3.删除方案 4.删除后一些后置处理 一次性删除存在的问题 1.1锁表卡死业务: 因为删除会长时间锁表,(尤其是大事务),其他查询和写入操作被阻塞。 影响:业务接口超时,页面卡死。 删除一千万条数据,耗时间是2个小时,在 阅读全文
posted @ 2025-08-17 21:15 cherry小樱桃 阅读(26) 评论(0) 推荐(0)
 

2025年8月15日

摘要: 问题:当消费速度跟不上服务端的发送速度的时候,消息就会堆积 问题 1:业务系统上下游的能力不匹配,造成堆积。 2.业务系统对消息的实时性要求高,短暂的堆积也无法接受。 阶段1:拉去消息: 1.客户端通过轮询从broker里面获取消息,放到本地缓存队列,这个阶段一般不会有性能问题 2.客户端把消息给业 阅读全文
posted @ 2025-08-15 20:30 cherry小樱桃 阅读(14) 评论(0) 推荐(0)
 

2025年8月14日

摘要: 排行榜的思考: 遇到排行榜,大家就想到数据库的orderby 比如:微信运动 这个实现是没有问题的,如果表的数据量少的话,推荐使用 大量数据的排行榜:如果在亿级别的数据,同时很多并发的情况下,怎么办? 使用上述的方法:磁盘扛不住,排序算不动,并发撑不起来: 当数据量较大:并且实时更新&&频繁查询的时 阅读全文
posted @ 2025-08-14 21:32 cherry小樱桃 阅读(12) 评论(0) 推荐(0)