Java开发碎碎念

1、数据库更新数据库时候

注意接收一下Update以后的返回值，判断有没有更新数据成功，如果没成功，那么要抛出异常。

2、关于锁的应用场景

①版本号乐观锁

优点：

1. 高性能：因为不需要加锁和解锁的开销，乐观锁的性能比悲观锁（如分布式锁）高。
2. 无死锁风险：乐观锁不使用锁机制，因此不存在死锁问题。
3. 简单实现：实现起来相对简单，不需要依赖额外的分布式锁服务。

缺点：

1. 适用场景有限：乐观锁假设大部分情况下不会发生竞争冲突，因此在高并发的写操作场景下，冲突会比较频繁，导致重试次数增加，性能下降。
2. 重试成本高：在冲突频繁的情况下，重试逻辑会增加系统的复杂度和开销。

使用场景：

1. 读多写少的场景：如商品浏览量计数、用户点击计数等。
2. 单机或小规模分布式系统：如中小型企业的业务系统。

②Redis分布式锁

优点：

1. 强制互斥：确保多个进程或线程在分布式环境下对资源的互斥访问，避免并发冲突。
2. 灵活性高：可以控制锁的粒度和策略，适用于各种复杂场景。
3. 适用范围广：适用于跨多个系统或服务的分布式环境。

缺点：

1. 性能开销大：获取和释放锁需要网络通信，性能开销较大。
2. 潜在死锁风险：虽然可以通过设置锁超时来避免死锁，但仍然需要谨慎设计。
3. 复杂度高：实现分布式锁需要依赖第三方组件（如 Redis、Zookeeper），且需要处理锁失效、锁超时等问题。

使用场景：

1. 高并发资源竞争场景：如分布式系统中的订单处理、库存扣减等。
2. 跨多个服务的协同操作：如分布式事务的协调控制。

3、延迟MQ

1. 性能和资源开销：

   • Redis：定期扫描有序集合会带来一些CPU开销，但由于Redis的高效内存操作，整体性能仍然较高。
   • RabbitMQ：消息持久化和复杂的消息路由机制可能带来更多的I/O和CPU开销，尤其在高并发场景下。

2. 可靠性：

   • Redis：主要在内存中操作，断电或重启后可能会丢失未持久化的消息，除非使用AOF或RDB持久化机制。
   • RabbitMQ：支持消息持久化和镜像队列，能够提供更高的可靠性和数据持久性。

Redis和RabbitMQ在实现延迟消息队列时，判断消息是否到了延迟时间并准备被消费的机制各具特点。Redis通过有序集合和定期扫描来实现，简单高效但需自行管理扫描逻辑；RabbitMQ通过TTL、死信队列或延迟消息插件实现，功能强大但伴随更高的系统资源开销。

(未完待更新)