- 博客(12)
- 收藏
- 关注
RSS订阅
原创 集合类在高并发场景下的总结及其正确使用
HashSet底层是HashMap的key、LinkedHashSet是在HashSet基础上添加链表结构，记录插入顺序、TreeSet基于TreeMap的key，按自然顺序或自定义比较器排序。常见的实现了List接口的类有：ArrayList、LinkedList、Vector、Stack、CopyOnWriteArrayList、SynchronizedList。适用于低频写 + 简单操作。在读操作和写操作时都会上锁，锁的是实例本身this，所有方法共用同一把锁，写竞争激烈时性能差。
2025-04-10 21:32:37
1198
原创 常见的限流算法
过了1.0s这个点后，会右移一小格，当前的单位时间段是0.2~1.2s，这个区域的请求已经超过限定的5了，已触发限流，实际上，紫色格子的请求都被拒绝。然后呢，每个小周期，都有自己独立的计数器，如果请求是0.83s到达的，0.8~1.0s对应的计数器就会加1。无法很好的处理流量突增的情况，在流量突增时，我们希望在系统平稳的同时，提升用户体验即能更快的处理请求，而不是和正常流量一样，循规蹈矩的处理，后面的令牌桶就可以轻松的实现。漏桶算法面对限流，就更加的柔性，不存在直接的粗暴拒绝。限流，也称流量控制。
2025-04-03 20:13:31
1428
原创 Mysql思维导图分享
MySQL学习思维导图大纲，在学习Mysql过程中记录的笔记和个人深度理解。如有错误欢迎指正，完整内容可通过文末链接获取。
2025-09-03 17:32:47
609
原创 Redis思维导图分享
这是思维导图的一个大纲，有需要的伙伴可以去文章末尾获取链接自取。这些都是笔者自己在学习Redis的过程中，记录的一些笔记，也包含了一些自己的深度理解。如有不对的地方，请指出。
2025-06-19 21:55:41
1406
2
原创 线上问题排查（OOM、CPU飙升）
摘要：本文介绍了OOM和CPU飙升问题的排查方法。OOM排查通过设置-Xmx参数限制堆内存，触发OOM后分析dump文件，发现内存被List对象占用260MB，最终定位到接口中持续存储新对象的问题。CPU飙升排查使用top命令发现占用100%的Java进程，通过线程转换和jstack分析定位到死循环代码行，最后杀死线程并修改代码。两种场景均采用日志分析、工具定位和代码修正的解决流程。
2025-06-13 21:28:38
1450
原创 登录时常见的认证手段
Token 是客户端持有的身份凭证，通常以字符串形式存在，用于替代传统的 Cookie-Session 模式。存储在客户端，通过 HTTP 请求头的。Cookie 是服务器发送到客户端（浏览器）的一小块数据（通常为键值对），由客户端存储并在后续请求中自动携带，是早期解决“状态维持”的核心方案。另外，也可以使用UUID作为Token存储在Redis中，后续请求获取Token之后与Redis的Token进行匹对。由于cookie是存储在客户端的，cookie中的数据容易被获取和篡改，因此其安全性不高。
2025-03-30 15:52:23
561
原创 三级缓存在高并发场景的简单应用
与此同时，本地缓存只支持被该应用进程访问，一般无法被其他应用进程访问，故在应用进程的集群部署当中，如果对应的数据库数据，存在数据更新，则需要同步更新不同部署节点的缓存数据来包保证数据一致性，复杂度较高并且容易出错，如基于 rocketmq 的发布订阅机制来同步更新各个部署节点。所以对于需要更改然后持久化的数据，需要注意及时保存，否则可能会造成数据丢失。由于本地缓存太小，从而很容易被淘汰，如果还没有来得及访问，本地缓存中的数据，就被淘汰了，那就失去了本地缓存的价值， 当然，本地缓存的命中率也会很低。
2025-03-28 21:35:26
603
原创 如何保障缓存和数据库的数据一致性
在更新完数据库之后，发送一条消息消息中间件，由消费者进行异步删除缓存，但是会有短暂的数据不一致，如果业务可以容忍的话，是无关紧要的。在A请求更新完数据库，删除缓存之前，B请求进行查询执行业务操作，会使用旧数据进行业务处理，造成短暂的数据不一致，这个场景发生在写少读多的高并发场景。更新完缓存后，如果数据库更新失败进行回滚，并不会对redis中的数据进行回滚，因此redis存储的是新数据，数据库存的是旧数据，造成了数据不一致。在更新完数据库之后，直接删除缓存，后续如果有请求查询数据，会去数据库读取最新的数据。
2025-03-27 18:00:24
510
原创 如何保证消息队列消费消息的顺序性
实际上，每一个消费者的消费端都是采用线程池实现多线程消费的模式，即消费端是多线程消费。RocketMQ生产者生产的消息会将其放入某个队列中，基于队列先进先出的特性，可以保证存入同一队列的消息可以顺序消费。普通发送模式下，生产者采用的是轮询的方式将消费均匀的分发到不同的队列中，然后被不同的消费者消费，如果同一组的消息在不同的队列，就无法保证消息消费的有序性。就行了，即通过订单ID%队列数量得到该ID的订单所投放的队列在队列列表中的索引，然后该订单的所有消息都会被投放到这个队列中。在消费的时候，还需要。
2025-03-27 17:55:31
1001
原创 深分页查询优化
使用子查询：select id,age,name from tb_user join (select id from tb_user where age > 10 limit 50000,100) temp on tb_user.id = temp.id;接着来到引擎层调用接口查询数据，在实际数据查询时，并不会直接定位到第50000条数据，而是先从第0条一直找到第50100条(在子查询时通过主键索引查询到符合条件的100条数据，再进行这100条数据的回表查询，减去了50000条数据的回表查询。
2025-03-26 14:04:52
307
原创 Bitmap和布隆过滤器实现数据去重
使用bitmap：使用redis的bitmap实现，以业务标识为key，用户上线就将用户id(一般使用的是雪花算法生成)作为偏移量存入bitmap中，下线则将对应位置0，极大节省了内存，如果数据太大，可以考虑对位图进行分片。使用bitmap：每个用户都分配一个独立的bitmap，然后以功能上线日期为起始索引，后续位索引=当前日期-功能上线日期=天数。在变量QQ号时，将bitmap对应位索引的位置1，如果已经为1，则记录到日志中。缺点：使用的内存大于bitmap，存在误判率，不适合对误判率要求0的场景。
2025-03-26 14:02:53
803
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人