阿呆的专栏

例如Slot案例中写入的三条数据对应的两条延迟消息（均为延迟时间：2023-04-16 20:00:00）之间，夹杂着一条更晚触发的延迟消息（2023-04-16 20:05:00）老版本延迟队列仅支持几个延迟时间，而不是任意延迟时间，新版本进行了升级，可以支持任意版本。

每个shard向cooridinating节点返回足够的信息，以允许它合并与重排序shard级别的结果至一个全局排序的结果集，结果集最大长度为请求需求的size。与"Query Then Fetch"相似，区别是初始分发阶段，它会去计算分布式TF值，以获取更准确的评分。与query_then_fetch区别在于，只有一个阶段，第一阶段就返回文档内容，即将两个阶段合二为一了。查询Segment缓存中的数据，因此ES是一个近实时数据，默认写入的数据1S内进入Segment。hot数据迁移至warm节点。

Java语言开发，API中不能使用枚举类型，否则服务端新增枚举会影响客户端批量请求的接口特点是高吞吐单个请求的接口特点是高并发就单个接口而言，吞吐与并发是互斥的，设计过程中可以基于实际的业务进行设计。就像jvm的Parallel GC与CMS GC的选择。...............

背景：基于redis实现分布式锁。客户端：lettuce-core-5.1.7.RELEASE。连接池：commons-pool2-2.6.2。

适配器模式踩坑

为什么要分库分表？单库表无论是存储还是cpu/网络等物理资源存在极限，对于日益增长的业务无法支撑分库分表设计默认按照主键作为分库分表的keyhash散列分库分表优劣优点：hash散列分布均匀，负载较为均衡缺点：扩容难扩容问题扩容需要数据rehash+数据迁移，当然可以选择业务低峰时逐个迁移做到业务无感，但是迁移的成本与数据量成正比可以学习参考HashMap的方案，扩容时避免rehash并且减少了迁移量，但是实用吗？为了成本当然时一台台扩容更为理想，不能每次扩容都成倍增长，该方案不适用

为什么需要分布式事务？随着互联网的高速发展，业务数据量级也已经不是单库表所能承担的，于是微服务与分库则应时而生，同时也引入了一些问题，最常见的案例：下单并支付动作需要触发，扣减库存以及账户余额。库存管理服务，账户管理服务两个微服务使用两个独立的数据库，而此时需要同时成功或失败回滚。​分布式事务实现方案常见的方案有如下几种本地消息表，方案最初有ebay提出（https://queue.acm.org/detail.cfm?id=1394128）TCC，TryConfirmCancelAT，Au

摘自曼彻斯特大学伊恩·沃森的讲座概述我们已经讨论过在单核上的性能优化局部性向量现在让我们优化一个共享内存程序两种架构：基于总线的共享内存机器（小规模）基于目录的共享内存机器（大规模）基于总线共享内存的体制基本情况很简单：![mesi-0.png](https://img-blog.csdnimg.cn/img_convert/dd0862f6138df347c18eb27621defb32.png#align=left&display=inline&he

netty模型基于rocketmq-4.7.1中netty部分源码分析模型简介ServerBootstrap，Server服务端ServerBootstrap.group，处理绑定请求。绑定服务器地址，监听服务器端口，构建Acceptor接受者提供服务接收客户端请求ServerBootstrap.childGroup，处理客户端数据请求、响应客户端数据。处理channel通道注册至Selector监听ServerBootstrap.childHandler，处理客户端请求，可以理解为业务线程池

写（发送）消息broker写消息处理器：SendMessageProcessorrocketmq为每个topic维护M个broker*N（默认值：16）个队列，其写入的并发性扩展性很强大![image.png](https://img-blog.csdnimg.cn/img_convert/1398dd5428d0a40040505d6a88a7970f.png#align=left&display=inline&height=459&margin=[object Object

脑裂问题HDFS 1.0 架构，图片取自：《Hadoop：The Definitive Guide》1.0问题namenode单点问题随着集群扩展，namenode管理文件元数据存在瓶颈2.0解决方案增加协调者（coordinator）管理一主多从的NameNode节点提供高可用的NameNodefederation联邦解决方案，可以理解为分片方案类似于分库分表脑裂问题（分区问题）正常情况下的协调者机房1与机房2出现网络故障后，机房2重新选举leader，导致脑裂问题如下。导

前言为什么选择命令、装饰器、责任链模式来聊，因为自己对这三个涉及模式的实现与理解有些吃力，最近思考再三有所领悟，记录分享一下。但是学习过程中牵扯出其他几个模式的，哎，蜀道难。也希望可以帮助到对这三个模式有所迷惑的小朋友，或者有哪些更好的理解与可以提出或纠正我自身理解的错误。总之是一个相互学习点的抛出本文类图均取自《Head First设计模式》命令模式有些不太好理解，结合一下案例就好理解了。dubbo中的telnet命令就是一个很好的案例，服务器端接口客户端请求处理的HeaderExchangeH

1. 业务文档梳理原业务流程图原业务依赖图2. 问题总结找出当前服务问题3. 问题解决方案针对问题列举解决方案新服务与旧服务的优缺点列举方案优缺点列举4. 技术文档梳理新框架流程图类图5. 测试点测试场景的脑图编写测试用例6. 风险点列举风险点风险规避方案...

缓存穿透什么是缓存穿透？缓存穿透是指查询大量的key实际不存在例如：数据库中存储的国内34个省级行政区域信息，id是1-34，缓存的key为id。客户查询35、36、0等等实际不存在的key。因为这些数据实际不存在，所以缓存中也无法命中，便需要服务查询数据库，如果大量此类查询会直接导致数据库扛不住甚至宕机等可能性解决方案方案1：将不存在的key缓存起来，超时时间设置得短一些优点：处理...

mapper数据库操作类，该包下mybatis中一般都是自动生成manager数据库中的相关操作，dto与po之间的转换，以及mapper中各个原子操作的组合使用，事务控制。避免manager层面使用cache层。因为cache层使用manager层的操作进行缓存加载，避免出现循环依赖。cache缓存类，一般使用manager包进行加载数据库数据至缓存。因此不要在manager中使用ca...