blog

Zebra是一个基于JDBC API协议上开发出的高可用、高性能的数据库访问层解决方案,简化了读写分离、分库分表的开发工作，使得业务方在分库分库、读写分离的情况下，依然可以像操作单个库那样去操作，屏蔽底层实现的复杂性，对业务透明。 读写分离在单台mysql实例的情况下，所有的读写操作都集中在这一个实例上。当读压力太大，单台mysql实例扛不住时，此时DBA一般会将数据库配置成集群，一个master(主库)，多个slave(从库)，master将数据通过binlog的方式同步给slave，可以将slave节点的数据理解为master节点数据的全量备份 对sql类型进行判断。如果是select等读请求，就走从库，如果是insert、update、delete等写请求，就走主库。 主从数据同步延迟问题。因为数据是从master节点通过网络同步给多个slave节点，因此必然存在延迟。因此有可能出现我们在master节点中已经插入了数据，但是从slave节点却读取不到的问题。对于一些强一致性的业务场景，要求插入后必须能读取到，因此对于这种情况，我们需要提供一种方式，让读请求也可以走主库，而主 ...

leaf是美团 推出的一个分布式ID生成服务，名字取自德国哲学家、数学家莱布尼茨的一句话：“There are no two identical leaves in the world.”Leaf具备高可靠、低延迟、全局唯一等特点在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识，对数据分库分表后需要有一个唯一ID来标识一条数据或消息 重写getid方法 12345678<bean id="idGen" class="com.dianping.pigeon.remoting.invoker.config.spring.ReferenceBean" init-method="init"> <property name="url" value="com.sankuai.inf.leaf.thrift.IDGen" /> <property name="interfaceName" value="com.sa ...

分片原理由于平台接入的数据达万级，消息队列积压严重，为提高消费端 ES 的写入，中间不单纯是一些写入，做各种各样的处理，插入到第三方表，整体流程耗时非常严重，使用方不能及时搜索到商品的信息，第一期的话是全部改成批量操作，充分利用系统资源，发现这些指标还是上不去，像一些非核心的逻辑，要求不是那么实时，那我就开一个异步线程来异步化，迭代到最后面，攒批多线程插入，就先拉一批数据到全局队列中去，再开一个线程池，启动线程池，对数据进行分片后多线程批次插入，ES 提供了 Bulk API 支持批量操作，当我们有大量的写任务时，可以使用 Bulk 来进行批量写入。 当前一个数据通过路由计算公式得到的值是 shard=hash(routing)%4=0，则具体流程如下： （1）数据写请求发送到 node1 节点，通过路由计算得到值为1，那么对应的数据会应该在主分片S1上。（2）node1节点将请求转发到 S1 主分片所在的节点node2，node2 接受请求并写入到磁盘。（3）并发将数据复制到三个副本分片R1上，其中通过乐观并发控制数据的冲突。一旦所有的副本分片都报告成功，则节点 node2将向nod ...

++ + 使用AIGC工具的优点（1）提高工作效率大型语言和图像AI模型可用于自动生成内容，例如文章、博客或社交媒体帖子。对于定期创建内容的企业和专业人士来说，是非常节省时间的工具，将成本显著降低效率，效率提高。 （2）提高内容质量AIGC生成的内容可能比人类创建的内容质量更高，因为AI模型能够从大量数据中学习并生成一些人类认知不到的一些内容。例如DALL · E 2 和 Google 的 Imagen 都可以通过文字来要求AI画出描述的具体内容，并且效果已经接近中等画师的水平。 （3）增加内容多样性首先，目前的AIGC多模态模型可以生成多种类型的内容，包括文本、图像和音视频等等；其次，AIGC生成的内容可以进行定制化、风格化迁移。 文本生成AI（搜索、文案、写作）以结构性新闻撰写、内容续写、诗词创作等细分功能为代表，基于NLP技术的文本生成可以算作是AIGC中发展最早的一部分技术，也已经在新闻报道、对话机器人等应用场景中大范围商业落地。 自然语言处理算法（NLP）目前以Transformer架构为核心进行迭代，它是一种采用自注意力机制的模型，能够根据输入数据各部分的重要性而分配不同的 ...

Mafka是美团自研的一个高可用、可拓展、高性能的分布式消息队列服务,底层基于Apache Kafka，广泛用于消息异步处理、应用解耦、流量削峰、发布/订阅模型等场景。Mafka为研发工程师提供全托管的消息队列服务，用户只需专注于业务开发无需部署运维。 用户场景 异步处理模式 消息发送者 可以发送一个消息而无须等待消费者响应。消息发送者将消息发送到一条 虚拟的通道（主题 或 队列）上，消息接收者则订阅或是监听该通道。一条信息可能最终转发给 一个或多个 消息接收者，这些接收者都无需对消息发送者做出同步回应，整个过程都是异步的。 应用系统之间的解耦合 发送者和接受者不必了解对方、只需要确认消息，比如发送和接收者可以是不同的系统，不同的语言编写的，地理上可以不在同一个地域 发送者和接受者不必同时在线 流量削峰 当在线api接口在应对高峰流量时，比如“秒杀”，“流量激增”时，如果接口处理能力有限，可以先将无法及时处理的请求发送给消息队列，后台处理，防止流量过大将api接口服务打死。 “秒杀”场景需要下游消费方的消费能力达到最大，业务方可以使用push类型消费组进行消费 发布/ ...

LightMerge是什么？LightMerge即轻量级Merge，目标是将多个分支快速合并到一个分支，合并操作相较 PR 来说更轻量级(不提供 diff 查看，评审，卡点等功能)，一般用于线下测试时快速生成集成分支。版本发版分支上线的内容由多个RD在多个分支开发实现，在上线前需要将多个开发分支的内容合并进集成分支进行发版。为此引入Code平台提供的git能力， 如何使用LightMerge？拥有仓库写权限或者管理员权限的用户可以使用LightMerge功能。 通过新建LightMerge可以新建一个多分支的合并，将多个源分支合并到目标分支中，重要的分支（如Master分支）最好设置为LightMerge保护分支，防止在整个LightMerge的过程中污染了重要分支代码 在源分支的添加中，最新加入的分支在最前面，因为LightMerge会按页面展示的分支顺序执行，保障修复LightMerge中发生冲突的分支添加后可最先被合并 通过Edit按钮可以修改基础分支、增加或删除源分支 通过Check按钮可以校验分支中是否冲突，如果有冲突，请按照对应的冲突信息解决 通过Refresh ...

为什么都要扩展为原来的2倍这是因为，将数组容量扩展为原来的两倍，可以在保证空间利用率的同时，最大限度地减少哈希冲突的发生。具体地说，如果将数组容量扩展为原来的 k 倍，虽然可以进一步降低哈希冲突的概率，但也会造成空间浪费；而如果将数组容量扩展为原来的 1.5 倍，虽然可以减少空间浪费，但也会增加哈希冲突的概率。因此，将数组容量扩展为原来的两倍，可以在空间利用率和哈希冲突之间取得一个较好的平衡。hash % length == hash & (length - 1)这个关系只有在length等于二的幂次方时成立，位运算能比%高效得多 扩容因子为什么是 0.75而HashMap中加载因子为0.75，是考虑到了性能和容量的平衡。 由加载因子的定义，可以知道它的取值范围是(0, 1]。 如果加载因子过小，那么扩容门槛低，扩容频繁，这虽然能使元素存储得更稀疏，有效避免了哈希冲突发生，同时操作性能较高，但是会占用更多的空间。 如果加载因子过大，那么扩容门槛高，扩容不频繁，虽然占用的空间降低了，但是这会导致元素存储密集，发生哈希冲突的概率大大提高，从而导致存储元素的数据结构更加复杂（用于 ...

MD5算法是Hash算法的一种，叫做讯息摘要演算法。在MD5算法中，这个摘要是指将任意数据映射成一个128位长的摘要信息。并且其是不可逆的，即从摘要信息无法反向推演中原文，在演算过程中，原文的内容也是有丢失的。 MD5算法大致分为4步完成： 第1步：进行数据填充整理 这一步是对要加密的数据进行填充和整理，将要加密的二进制数据对512取模，得到的结果如果不够448位，则进行补足，补足的方式是第1位填充1，后面全部填充0。 第2步：记录数据长度 经过第一步整理完成后的数据的位数可以表示为N512+448，再向其后追加64位用来存储数据的长度，比如数据的长度为16字节，则用10000来填充后64位。这一步做完后，数据的位数将变成(N+1)512。 第3步：以标准的幻数作为输入 MD5的实现需要每512个字节进行一次处理，后一次处理的输入为前一次处理的输出，因此，在循环处理开始之前，需要拿4个标准数作为输入 第4步：进行N轮循环处理，将最后的结果输出 这一步重要的是每一轮的处理算法，每一轮处理也要循环64次，这64次循环被分为4各组，每16次循环为一组，每组循环使用不同的 ...

kconf

docker run命令的作用是在一个全新的Docker容器内部运行一条指令。Docker在执行这条命令的时候，所做工作可以分为两部分：第一，创建Docker容器所需的rootfs；第二，创建容器的网络等运行环境，并真正运行用户指令。因此，在整个执行流程中，Docker Client给Docker Server发送了两次HTTP请求，第二次请求的发起取决于第一次请求的返回状态。Docker run命令执行流程如图5.2。 图5.2 docker run命令执行流程示意图 如图，图中标记的红色箭头表示docker run命令在发起后，Docker所做的一系列运行。以下逐一分析这些步骤。 (1) Docker Client接受docker run命令，解析完请求以及收集完请求参数之后，发送一个HTTP请求给Docker Server，HTTP请求方法为POST，请求URL为”/containers/create? “+”xxx”； (2) Docker Server接受以上HTTP请求，并交给mux.Router，mux.Router通过URL以及请求方法来确定执行该请求的具体handl ...