- 博客(16)
- 收藏
- 关注
RSS订阅原创 黑名单存储与查询优化：从数据库到内存结构的高效实现
黑名单管理在现代应用中扮演着重要的角色，选择合适的存储和查询方案对于系统的性能和可扩展性至关重要。从简单的数据库实现到高效的内存数据结构，再到布隆过滤器、布谷鸟过滤器和Redis Bitmap等先进技术，每种方案都有其独特的优缺点。在实际开发中，我们需要根据黑名单数据量、查询频率、误判容忍度等具体需求，综合考虑各种因素，选择最合适的方案。同时，随着技术的不断发展和应用场景的多样化，新的解决方案和优化策略也在不断涌现。未来，我们可以期待更加高效、智能的黑名单管理系统，为应用的安全和性能提供更强大的保障。
2025-03-13 00:35:10
1977
原创 深拷贝和浅拷贝
浅拷贝：只复制对象本身和值类型字段，引用类型字段共享。深拷贝：递归复制对象及其引用类型字段，生成完全独立的新对象。实现深拷贝的方法Cloneable接口：适合简单对象结构，性能较高。序列化和反序列化：适合复杂对象结构，但性能开销较大。手动递归复制：灵活，但代码复杂度较高。根据实际需求选择合适的深拷贝方法，可以有效避免对象共享带来的问题，同时提高代码的可维护性和可扩展性。
2025-02-25 00:13:36
609
原创 数据库无锁变更
DML 无锁数据变更可将单个 SQL 拆分成多个批次执行，能满足大量数据变更需求，如历史数据清理、全表更新字段等，保证执行效率，减小对数据库性能和空间的影响。场景：需删除订单表中3年前的历史数据（约300万行），直接执行全表删除可能导致锁表或触发Binlog限制。工具特性：DMS自动生成备份脚本（记录旧数据），NineData支持根据数据库负载动态调整批次大小。当您提交了无锁结构变更工单，DMS会自动进行如下操作，以实现无锁结构变更。，并在批次间加入缓冲时间（如1秒）以减少业务影响。
2025-02-19 18:14:38
436
原创 Java线程池实现原理及实践
面对业务中使用线程池遇到的实际问题，我们曾回到支持并发性问题本身来思考有没有取代线程池的方案，也曾尝试着去追求线程池参数设置的合理性，但面对业界方案具体落地的复杂性、可维护性以及真实运行环境的不确定性，我们在前两个方向上可谓“举步维艰”。最终，我们回到线程池参数动态化方向上探索，得出一个且可以解决业务问题的方案，虽然本质上还是没有逃离使用线程池的范畴，但是在成本和收益之间，算是取得了一个很好的平衡。
2025-02-18 00:10:16
2165
原创 如何实现可靠的数据同步
增量表写入压力大，全表扫描可能拖慢主库。高（需MQ、幂等设计、事务一致性）消息持久化+状态表跟踪，容错能力强。高频、高实时性、系统规模较大的场景。依赖数据库事务，失败重试机制简单。低频、低实时性、技术栈简单的场景。MQ异步解耦，对主库压力小。高（消费者可分布式扩展）低（依赖定时任务间隔）高（MQ消息实时推送）
2025-02-16 22:16:52
587
原创 常用的数据同步方式
定时任务低低低低频增量同步，容忍延迟数据库触发器高中中简单实时同步，低并发场景消息队列中高中高高并发、解耦需求，允许最终一致性接口实时调用极高高中强实时性，对方接口稳定日志监听（CDC）高低高无侵入精准同步，技术要求高。
2025-02-16 19:18:55
484
原创 优雅地使用 AOP 生成动态的操作日志
这个操作日志的模板最后记录的内容是这样的格式：修改了订单的配送员：从 “10090”，修改到 “10099”，显然用户看到这样的操作日志是不明白的。缺点也很明显，局限性太高，只能针对数据库的更改做操作日志记录，如果修改涉及到其他团队的 RPC 的调用，就没办法监听数据库了，举个例子：给用户发送通知，通知服务一般都是公司内部的公共组件，这时候只能在调用 RPC 的时候手工记录发送通知的操作日志了。系统日志的可读性要求没那么高，日志中会包含代码的信息，比如在某个类的某一行打印了一个日志。
2025-02-16 18:07:39
615
原创 ThreadLocal、InheritableThreadLocal、TransmittableThreadLocal三者区别
子线程继承父线程的变量值，但可以通过 childValue 方法自定义继承的值。通过合理选择这三种工具，可以满足不同场景下的线程变量管理需求。
2025-02-16 16:16:47
589
原创 常用的系统操作日志记录实现方式
通过拦截方法调用（如Controller层或Service层），在方法执行前后插入日志记录逻辑，实现业务代码与日志逻辑的解耦。将日志事件发送到消息队列（如Kafka、RabbitMQ），由消费者异步处理，避免阻塞主流程。通过监听数据库的Binlog日志（如MySQL），解析数据变更事件（增删改），触发日志记录。通过数据库触发器（如MySQL Trigger）在数据变更时自动记录日志。数据库层面的数据变更审计（如订单状态变更、用户信息修改）。业务逻辑层的操作记录（如接口调用、方法执行耗时）。
2025-02-16 00:23:12
1262
原创 美团分布式ID方案Leaf
Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。Leaf-segment方案可以生成趋势递增的ID，同时ID号是可计算的，不适用于订单ID生成场景，比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的。这样做到了对三方组件的弱依赖。针对服务自身的监控，Leaf提供了Web层的内存数据映射界面，可以实时看到 所有号段的下发状态。
2025-02-15 20:55:23
2139
原创 各种分布式ID实现方式对比
SnowFlake 算法是 Twitter 开源的分布式 ID 生成算法。这 64 个 bit 中，其中 1 个 bit 是不用的，然后用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 ID，12 bit 作为序列号。UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000。最常用的是版本 1 和版本 4。
2025-02-15 13:58:47
673
原创 各种登录方式梳理
方案状态管理扩展性安全性适用场景有状态低中传统 Web 应用JWT无状态高中高分布式系统、移动端有状态高高需会话控制的企业应用OAuth 2.0依赖第三方高高第三方登录集成双 Token 机制有状态高极高高安全需求场景双 Token 三验证有状态高极高高安全需求场景通过双 Token 三验证机制，系统在安全性、用户体验和灵活性之间取得了平衡，是登录鉴权模块的最佳实践方案。
2025-02-14 00:44:54
783
原创 双 Token 三验证机制
有效期设置矛盾短有效期：用户需要频繁登录，体验差。长有效期：Token 被截取后，黑客可以长期使用，安全性低。无状态性Token 一旦颁发，服务端无法主动使其失效（除非过期）。即使检测到 Token 异常（如泄露），也无法立即失效。双 Token 三验证机制通过和的组合，解决了单 Token 模式下的有效期矛盾和无状态性问题。通过 Redis 存储，实现了 Token 的主动失效和会话控制，既提升了安全性，又优化了用户体验。
2025-02-14 00:06:22
895
原创 双 Token 机制的原理
双 Token 机制通过和的组合，解决了单 Token 机制中过期时间设置的矛盾问题，既保证了安全性，又提升了用户体验。实际项目中，需要前后端密切配合，确保流程的顺畅和安全。
2025-02-13 23:51:28
1051
原创 JWT加密解密过程
JWT 的签名过程：对 Header 和 Payload 进行签名，生成 Token。JWT 的验证过程：验证签名是否有效，确保 Token 未被篡改。JWT 的加密和解密：默认情况下，JWT 不加密数据，但可以通过 JWE 实现加密。
2025-02-13 23:17:38
736
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人