JDDTechTalk的博客

如何处理所有Replica都不工作？Controller leader：当broker启动的时候，都会创建KafkaController对象，但是集群中只能有一个leader对外提供服务，这些每个节点上的KafkaController会在指定的zookeeper路径下创建临时节点，只有第一个成功创建的节点的KafkaController才可以成为leader，其余的都是follower。而粘性会保证跟上一次的尽量一致，只是将新的需要分配的分区，均匀的分配到现有可用的消费者中即可，这样就减少了上下文的切换。

京东科技CDP画像平台通过对用户分群，针对不同的用户投放以不同形式的不同内容，实现千人千面的精准投放，最终实现用户的增长。对外提供多样的数据服务，服务于不同的业务，以支持精准营销、精细化运营，智能外呼等营销场景。随着时代的发展，离线人群已经不能满足日益增长的运营需求。从去年开始,CDP着手建设数据实时化，目前已经完全做到了人群命中实时计算。作者：京东科技 梁发文来源：京东云开发者社区 转载请注明来源。

联邦查询可以很好的解决这个问题，使用统一的查询引擎屏蔽了不同olap的引擎的专有DSL，大大提升了开发效率和学习成本，同时可以用ONE SQL方式整合来自不同数据源的指标形成新的指标，从而提高了指标的复用性。改造后，我们在数据存储层引入了StarRocks，StarRocks提供了极速的单表和多表查询能力，同时以StarRocks为基础我们打造了统一查询引擎，统一查询引擎根据京东的业务特点增加数据源和聚合下推等功能，UData在统一查询引擎的基础上统一了数据分析和数据服务功能。

sql(Structured Query Language: 结构化查询语言)是高级的费过程化编程语言,允许用户在高层数据结构上工作, 是一种数据查询和程序设计语言, 也是(ANSI)的一项标准的计算机语言. but… 目前仍然存在着许多不同版本的sql语言,为了与ANSI标准相兼容, 它们必须以相似的方式共同地来支持一些主要的命令(比如SELECT、UPDATE、DELETE、INSERT、WHERE等等).

本章以实时OALP引擎Clickhouse(简称ck)为例, 以其面向场景, 架构设计, 细节实现等方面来介绍, 深度了解其如何成为了OLAP引擎中的性能之王.

本文以一个线上问题为背景，对 Mysql 中的各种锁机制进行了详细的总结，分析了各个锁的加锁时机和具体使用场景，其中特别要注意间隙锁的使用，因间隙锁和间隙锁之间不互斥，当多个事务之间并发执行时很容易形成死锁作者：京东物流 张弓言来源：京东云开发者社区 自猿其说Tech 转载请注明来源。

当使用Spring Boot开发数据库应用时，读写分离是一种常见的优化策略。读写分离将读操作和写操作分别分配给不同的数据库实例，以提高系统的吞吐量和性能。

之前遇到过一个由MySQL间隙锁引发线上sql执行超时的场景，记录一下。

了解查询的核心原理，对比 SQL 查询优化技巧在 h2database 中的落地实现。：为了贴近实际应用，本文 Code Insight 基于 BTree 存储引擎。

本文主要以介绍方法为主，落地过程可以归纳为方案->收益测算->数据安全验证->系统稳定性验证->灰度与回滚。文中的账单系统通过step1大表压缩32%，step2大JSON字段序列化12%，step3删除无效数据10%，3个方案的顺利落地，有效的减少了50.7%的磁盘空间，成本下降也非常显著。最后，希望此文能够给还在迷茫，不知从何处下手落地数据库存储成本降低的同学一些启发和灵感，以上。作者：京东科技 李阳来源：京东云开发者社区 转载请注明来源。

本文采用一张简单的架构图说明了MySQL查询中使用的组件和组件间关系。解析了一条sql语句从客户端请求mysql服务器到返回给客户端的整个生命周期流程。

我们应对并发场景时一般会采用下面方式去预估线程池的线程数量，比如QPS需求是1000，平均每个任务需要执行的时间是t秒，那么我们需要的线程数是t * 1000。但是在一些情况下，这个t是不好估算的，即便是估算出来了，在实际的线程环境上也需要进行验证和微调。比如在本文所阐述分页查询的数据项组合场景中。1、数据组合依赖不同的上游接接口， 它们的响应时间参差不齐，甚至差距还非常大。有些接口支持批量查询而另一些则不支持批量查询。有些接口因为性能问题还需要考虑降级和平滑方案。

写分页查询接口，在进行第N页查询时，出现与第一前面页码的数据一样的记录。在MySQL中分页查询，我们经常会用limit，如:limit(0,20)表示查询第一页的20条数据，limit(20,20)表示查询第二页的数据。业务上我们通常也会在分页的时候加上排序 order by;但是当limit和order by一起使用的时候，有可能会出现第N页的数据，竟然和前面页码的数据有重复使用上述SQL查询的时候，很有可能和LIMIT 20,20查出相同的某条数据。

由于测试环境JED申请比较繁琐，所以Eone提供了单机版Mysql供用户使用，近期Eone搭建Mysql5的时候发现莫名被kill了，容器规格是4C8G，磁盘30G这不科学，之前都是可以的，镜像没变，配置没变，咋就不行了呢，一定不是我的问题，是机器的问题。

index merge(索引合并)：该数据库查询优化的一种技术，在mysql 5.1之后进行引入，它可以在多个索引上进行查询，并将结果合并返回。该死锁问题是因为优化器使用了合并索引问题导致的，最终通过新建一个联合索引来解决这个问题。参考文档：1作者：京东工业 李小辉来源：京东云开发者社区 转载请注明来源。

基于国家对信创项目的大力推进，为了自主可控的技术发展，基础组件将逐步由国产组件替代，因此从数据库入手，将弹性库JED部署在 国产华为鲲鹏机器上(基于ARM架构)进行调优，与Intel (X86)进行性能对比。调优前：背景压力50%时，JED on 鲲鹏 读性能是 Intel 的 58%，写性能为68%

随着业务的快速变化和技术的不断发展，系统面临着诸多挑战，例如流量峰值、依赖服务故障、硬件故障、网络中断、软件缺陷等，这些因素都可能影响到系统的正常运行。在这种背景下，弹性设计（Resilience Design）应运而生。弹性设计是一种系统的设计和构建方法，。它的目标是使系统能够在面临压力和不确定性时，保持服务可用性和性能，而不是简单地在问题出现后进行修复。弹性设计考虑到了系统可能会遭受的各种攻击，包括物理攻击、网络攻击、软件错误等，并采取了相应的预防措施。

上一篇内容《从2PC和容错共识算法讨论zookeeper中的Create请求》介绍了保证分布式事务提交的两阶段提交协议，而XA是针对两阶段提交提出的接口实现标准，本文则对XA进行介绍。

private:......IO 成本：从磁盘或内存读取数据页的成本。CPU 成本：访问记录需要消耗的 CPU 成本。导入成本：这一项一直没被使用，先忽略。内存成本：这一项指的是占用内存字节数，计算 MRR（Multi Range Read）方式读取数据的成本时才会用到，也先忽略。全表扫描的成本就只剩 IO 成本、CPU 成本这两项了。

这篇主要介绍对慢 SQL 优化的一些手段，而在讲解具体的优化措施之前，我想先对 EXPLAIN 进行介绍，它是我们在分析查询时必要的操作，理解了它输出结果的内容更有利于我们优化 SQL。为了方便大家的阅读，在下文中规定类似 key1 的表示二级索引，key_part1 表示联合索引的第一部分，unique_key1 则表示唯一二级索引，primary_key 表示主键索引。

本文简单介绍了读写分离架构，和出现主从延迟后，如果我们用的读写分离的架构，那么我们应该怎么处理这种情况，相信在日常我们的主从还是或多或少的存在延迟。本文介绍的几种方案，有些方案看上去十分不靠谱，有些方案做了一些妥协，但是都有实际的应用场景，需要我们根据自身的业务情况，合理选择对应的方案。

在这个燥热的夏天，又突然收到告警，分库分表的主键冲突了，这还能忍？不，坚决不能忍，必须解决掉！后面咱们慢慢道来是如何破局的，如何走了一条坎坷路……

数据一致性通常讲的主要是数据存储系统，主从mysql、分布式存储系统等，如何保证数据一致性，比如说主从一致性，副本一致性，保证不同的时间或者相同的请求访问这种主从数据库时访问的数据是一致性的，不会这次访问是结果A下次是结果B。

当使用了多个数据库来提供服务时，最为关键的点是如何让每一个数据库比较均匀的承担压力，而不至于其中的某些数据库压力过大，某些数据库没什么压力。这其中的关键点之一就是拆分键的设计。

MySQL服务端配置对使用方来说是不可更改的，需要联系DBA进行操作。这些配置操作对我们来说是一个黑盒，但是了解核心配置可以帮助我们快速定位数据库问题原因。

最近因需求改动新增了一些数据库表，但是在定义表结构时，具体列属性的选择有些不知其所以然，索引的添加也有遗漏和不规范的地方，所以我打算为创建一个高性能表的过程以实战的形式写一个专题，以此来学习和巩固这些知识。

典型的丢失更新问题，可以通过对数据库读操作加锁或者改变数据库的隔离级别为可串行化使事务串行执行的方式进行避免。下面我会将大家在讨论避免丢失更新问题时提出的方案进行介绍，并尽可能的用代码来表现它们。

本文是想利用AI赋能服装设计师，设计好看、好穿、好卖的服装，利用GPT+数据洞察、柔性快反+数智化供应链以及AIGC降低设计门槛和库存成本，快速反应市场时尚流行趋势，并进行落地实践

不论是ACID事务还是基于流处理系统的分布式事务，它们都保证数据的完整性。因为违反及时性可能会令人困惑，不过这只是暂时的，但是如果违反完整性，那么它的结果可能是灾难性的。违反一致性，最终一致性；违反完整性，永无一致性，是最好的概括。

复制，即在不同的节点上保存相同的副本，提供数据冗余。如果一些节点不可用，剩余的节点仍然可以提供数据服务，这些节点可能部署在不同的地理位置，以此来改善系统性能

魔笛活动平台要记录每个活动的用户行为数据，帮助客服、运营、产品、研发等快速处理客诉、解决线上问题并进行相关数据分析和报警。可以预见到需要存储和分析海量数据，预估至少几十亿甚至上百亿的数据量，所以需要选择一款能存储海量数据的数据库。由于是通过接收MQ存储或者API方式存储，所以对实时写入性能也有一定要求。同时可能后续还需要一些实时数据分析等

本文介绍了分库分表的概念及优势,以及sharding-jdbc分库分表中间件,探究了sharding-jdbc的路由规则的执行流程

本文主要从TiDB的各类组件为起点，了解它的基础架构，并重点分析它在存储架构方面的设计，探究其如何组织数据，Table中的每行记录是如何在内存和磁盘中进行存储的。

InnoDB存储引擎最早由Innobase Oy公司开发（属第三方存储引擎）。从MySQL 5.5版本开始作为表的默认存储引擎。该存储引擎是第一个完整支持ACID事务的MySQL存储引擎，特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读，非常适合OLTP场景的应用使用。目前也是应用最广泛的存储引擎。

大促备战，最大的隐患项之一就是慢sql，带来的破坏性最大，也是日常工作中经常带来整个应用抖动的最大隐患，而且对sql好坏的评估有一定的技术要求，有一些缺乏经验或者因为不够仔细造成一个坏的sql成功走到了线上，等发现的时候要么是造成了线上影响、报警、或者后置的慢sql采集发现，这时候一般无法快速止损，需要修改代码上线、或者调整数据库索引。

本文理论结合实践，通过BTree 索引的设计和实现，更好的理解数据库索引相关的知识点以及优化原理。

本文从 Commons DBCP testOnBorrow 的作用机制着手，管中窥豹，从一点去分析数据库连接池获取的过程以及架构分层设计。以下内容会按照每层的作用，贯穿分析整个调用流程。

文章从常用的关系型数据库 MySQL 的分库分表Join 分析，再到非关系型 ElasticSearch 来分析 Join 实现策略。逐步深入Join 的实现机制。

为了保证统计数据的准确性，比如订单金额，一个常用的方法是在查询时增加final关键字。那final关键字是如何合并数据的，以及合并的数据范围是怎样的，本文就对此做一个简单的探索

本文针对 MySQL 数据库的 InnoDB 存储引擎，介绍其中索引的实现以及索引在慢 SQL 优化中的作用。本文主要讨论不同场景下索引生效与失效的原因。