HanHanry-CSDN博客

原创源码学习1

枚举类可以提供标识和分类的功能，提高代码的可读性和可维护性，确保类型安全，方便扩展和维护，并集中管理票务过滤器链的标识。这样可以使代码更加规范、健壮和灵活。可能是一个自定义的类或接口，用于封装和管理分布式缓存的操作。它可能是一个单例模式的实现，通过。是一个方法调用，用于获取分布式缓存的实例。方法获取分布式缓存的唯一实例。

2024-03-20 01:45:00 248 1

原创创建订单明细与乘车人的关联表，分库分表规则同订单，完成乘车人账号登录查询本人车票功能。

*业务场景：**在12306购票的时候，可以允许添加多个乘车人，并且允许乘车人没有12306的账号回顾一下，咱们订单和订单明细表是按照用户 ID 后六位进行分库分表的，如果是购票用户查看自己的本人车票，通过用户 ID 就能查询。但是，购票时乘车人可能是没有账号的，这个怎么解决？：因为乘车人数据中唯一起到标识作用的也就是证件号，而注册用户证件号也是必须得，因此通过证件号进行数据关联。订单明细表是通过用户ID后六位查询的，但是路由表是按照证件号查询的，规则按照证件号进行HASH_MOD方式分库分表即可；

2024-03-19 21:31:54 135

原创通过 Redis Lua 脚本原子特性，完成用户购票令牌分配，通过令牌限流以应对海量用户购票请求。

但是令牌通会以固定速率生成令牌，但是咱们这个不会，而是将没有出售的座位当作一个个令牌放到一个容器中。用户购票需要去令牌容器获取令牌，成功则可以进入接下来的流程，获取失败直接返回，获取令牌后，令牌也会相对应的减少避免超卖。，大量的抢票请求卡在获取分布式锁阶段（一般tomcat同一时间最多200个请求）因此大量请求会因为分布式锁的申请而发生阻塞，导致请求无法快速处理。，为了避免这种情况，我们需要按照公平锁的方式请求和释放锁，使用后的场景就是释放锁后再获取锁要严格按照请求分布式锁的先后顺序执行。

2024-03-19 21:30:48 376

原创使用 BinLog 配合 RocketMQ 消息队列完成 MySQL 数据库与 Redis 缓存之间的数据最终一致性。

我们明白，若监听了 t_seat 表的 Binlog 数据变化，即使对任意字段进行修改，都会引发变更流程，从而将数据传送至 RocketMQ 消息队列，随后客户端会消费此消息。因此，在此阶段，若非预期的数据变动，可直接过滤。如果你想要最终一致性可以使用Binlog异步更新缓存的方案，如果缓存实时性要求比较高，使用先写数据库再删缓存方案。真实场景中根据具体业务需求和系统架构，可以选择适合的方案或组合多种方案，这些方案最终目的是在解决缓存和数据库之间的一致性问题，以确保数据的正确性和可靠性；

2024-03-19 21:29:30 552

原创封装缓存组件库避免注册用户时，用户名全局唯一带来的缓存穿透问题，减轻数据库访问压力；

为了解决布隆过滤器无法删除的问题，我们再加一层缓存来存储已注销用户名，实现了用户名的可复用性。此外，为了防止缓存结构过大带来的问题，我们对缓存进行了分片处理，有效减轻了存储和查询的负担。综上所述，综合考虑业务需求和系统性能，采用布隆过滤器结合缓存的解决方案是一个比较理想的解决方案，可以有效防止缓存穿透，并提升系统的性能和用户体验。：缓存穿透是指在使用缓存系统时，恶意或频繁地请求一个不存在于缓存中的数据，导致每次请求都需要查询数据库或其他数据存储系统，从而绕过了缓存的效果，严重影响系统性能。

2024-03-19 21:28:34 404

原创通过 RocketMQ 延时消息特性，完成用户购票 10 分钟后未支付情况下取消订单功能；

但是存在几个问题：1.不够精确，过期时间通过定时器实现的，可能存在误差，对于某些时间要求较高的场景不合适。 3.分库分表问题：拿 12306 来说，订单表按照用户标识和订单号进行了分库分表，那这样的话，和上面说的根据订单创建时间去扫描一批订单进行关闭，自然就行不通。 RabbitMQ 的延时消息特性，我们可以轻松实现订单十分钟延时关闭功能，比较难搞定的是可用性问题，RabbitMQ 在可用性方面较弱，部分场景下会存在单点故障问题。，将订单状态设置为关闭状态。为了处理订单关闭消息，

2024-03-19 21:27:54 350

原创使用责任链模式重构请求数据准确性检验，比如：查询购票、购买车票下单以及支付结果回调等业务；

具体实现：首先是定义购票责任链过滤接口，其次是对列车购买过滤器的实现，将每个需要验证的业务进行实现类编写，其中重写hanlder方法为具体的业务代码，并定义Order，代表在责任链中验证的顺序。并且，其中的代码不具备开闭原则（一旦需求的变更就会导致代码的修改，这不仅会增加代码风险，还会增加我们的开发、测试和维护成本），以及代码的扩展性，整体来说复杂且臃肿； 2.购票请求用户传递的参数是否正确，比如：车次ID是否存在、出发站点和到达站点是否存在等。，责任链中的业务检测流程有很多，最后对购票流程使用过滤器。

2024-03-19 21:26:48 398

原创 AILearning 吴恩达 L1 Week2 02 用神经网络思想实现Logistic回归（Cat）

pyL 1 Week 2 02 实现猫的识别

2022-06-26 20:18:53 367

Kooooooooooo的博客