因为目前 Broker 端日志段新增倒计时是全局设置，这就是说，在未来的某个时刻可能同时创建多个日志段对象，这将极大地增加物理磁盘 I/O 压力。有了 rollJitterMs 值的干扰，每个新增日志段在创建时会彼此岔开一小段时间，这样可以缓解物理磁盘的 I/O 负载瓶颈。

程序员基础掌握得好学新东西真的就快么？

如果希望 Value 以 JSON 保存并带上类型信息，更简单的方式是，直接使用 RedisSerializer.json() 快捷方法来获取序列化器。

尽量将业务逻辑写在业务代码中，让数据库只做“读写数据”的事情。因此，这类方法的应用还是比较广泛的

使用 addSuppressed 方法把 finally 中的异常附加到主异常上

把原始异常作为转换后新异常的 cause，原始异常信息同样不会丢

我不建议在框架层面进行异常的自动、统一处理，尤其不要随意捕获异常。但，框架可以做兜底工作

不在业务代码层面考虑异常处理，仅在框架层面粗犷捕获和处理异常

Controller 层往往会给予用户友好提示，或是根据每一个 API 的异常表返回指定的异常类型，同样无法对所有异常一视同仁

如果使用 Java8 以上版本可以使用 Arrays.stream 方法来转换，否则可以把 int 数组声明为包装类型 Integer 数组：

使用 UpdateWrapper (3.x)

忽略null值的判断

删除元素实际上调用的就是list.remove()方法，但是它多了一个操作

这就最大程度地减少了事务之间的锁等待，提升了并发度

最可能造成锁冲突、最可能影响并发度的锁的申请时机尽量往后放

把innodb_flush_neighbors的值设置成0。因为这时候IOPS往往不是瓶颈，而“只刷自己”，就能更快地执行完必要的刷脏页操作，减少SQL语句响应时间

普通索引和change buffer的配合使用，对于数据量大的表的更新优化还是很明显的

对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统

由于线程池在工作队列满了无法入队的情况下会扩容线程池，那么我们是否可以重写队列的 offer 方法，造成这个队列已满的假象呢？

对于执行比较慢、数量不大的 IO 任务，或许要考虑更多的线程数，而不需要太大的队列。

由于线程池在工作队列满了无法入队的情况下会扩容线程池，那么我们是否可以重写队列的 offer 方法，造成这个队列已满的假象呢？

由于我们 Hack 了队列，在达到了最大线程后势必会触发拒绝策略，那么能否实现一个自定义的拒绝策略处理程序，这个时候再把任务真正插入队列呢

队列来做缓冲。

对于执行比较慢、数量不大的 IO 任务，或许要考虑更多的线程数，而不需要太大的队列。

任何时候，都应该为自定义线程池指定有意义的名称，以方便排查问题

禁止使用这些方法来创建线程池，而应该手动 new ThreadPoolExecutor 来创建线程池

tem.lock.tryLock(10, TimeUnit.SECONDS)

因为无需默认构造函数就可以反射生成对象，这个属性在很多的序列框架可以使用，比如 xml 转换成 bean

比较理想的机制是，在alter table语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃

使用参数–single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。

super.getQueue() instanceof TaskQueue

只有在真正的多核CPU上才可能得到加速（通过多线程）

alter table T engine=InnoDB

第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的

mysql_reset_connection来重新初始化连接资源

都会用 Arrays.copyOf 创建一个新数组，频繁 add 时内存的申请释放消耗会很大

RabbitMQ版可用于单体应用被拆解为微服务后不同微服务间的通信

长事务死锁等各种风险

只需要发布一个产品ID变更的通知，由下游系统来处理，可能更为合理

信息采集处理

for the fastest possible throughput, manual acks should be disabled.

retry只能在自动ack模式下使用。如果一定要在手动ack模式下使用retry功能，需保证消息能在有限次重试过程中可以重试成功，否则超过重试次数，又没办法执行ack或者nack，消息就会一直处于unack,并不会转发到死信队列

建议消费者在 visibilityTimeout 时间内消费成功后需要调用（batch）DeleteMessage 接口删除该消息，否则该消息将会重新变成为 active 状态，此消息又可被消费者重新消费，保证消息至少消费一次，但是不能保证幂等性， 业务侧需要有去重逻辑。

您可以将消费过的去重 key 缓存（如 KV 等），然后每次消费时检查去重 key 是否已消费过。去重 key 缓存可以根据消息最大有效时间来淘汰。CMQ 提供了队列当前最小未消费消息的时间（min_msg_time），您可以使用该时间和业务生产消息最大重试时间来确定缓存淘汰时间。存在多个消费者时，去重 key 缓存就需要是分布式的

去重 key

采取 Pull 的方式问题就简单了许多，由于 Consumer 是主动到服务端拉取数据，此时只需要降低自己访问频率即可。举例：如前端是 flume 等日志收集业务，不断向 CMQ 生产消息，CMQ 向后端投递，后端业务如数据分析等业务，效率可能低于生产者。

AmqpRejectAndDontRequeueException 异常的时候，则消息会被拒绝，且 requeue = false（不重新入队列）

如果channel.basicNack(8, false, false);表示deliveryTag=8的消息处理失败且将该消息直接丢弃。

在需要使用消息的return机制时候，mandatory参数必须设置为true

see that the utilisation increases with the prefetch limit until we reach a limit of about 30. After that the network bandwidth limitation starts to dominate and increasing the limit has no further benefit

分散治理（Decentralized Governance）

基础设施自动化，如 CI/CD 的长足发展，大大降低了构建、发布、运维工作的复杂性。

另外，尽管在分布式中，我们要想处理好一致性的问题也很困难，很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻，一致性问题这些必要的代价是值得付出的。

在单体服务中，通常一个系统的各个功能模块会使用同一个数据库，虽然这种中心化的存储确实天生就更容易避免一致性的问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。

避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程

这一点在真正实践的时候，其实多少都会留点儿宽松的处理余地。因为大多数的公司都不会在某一个服务用 Java，另一个用 Python，下一个用 Golang，而是通常都会统一主流语言，甚至会有统一的技术栈或专有的技术平台。

如果本应该归属同一个产品内的功能，被划分在了不同的团队当中，那就必然会产生大量的跨团队沟通协作，而跨越团队边界，无论是在管理、沟通，还是在工作安排上，都会产生更高的成本。高效的团队，自然会针对这个情况进行改进，而当团队和产品磨合调节稳定了之后，就会拥有一致的结构

functions should be relatively short and ideally only do one specific thing