繁华流年间

来一个大的介绍：ElasticSearch的性能优化的几大方面总的来说，ElasticSearch的性能优化，可以从以下方面的考虑： 硬件层面的优化： 机器分配，机器配置，机器内存，机器CPU，机器网络，机器磁盘性能 系统层面的优化： 文件句柄优化、swap关闭 ElasticSearch集群层面的优化 合理分配节点， 合理分配参加竞选Master的节点 ElasticSearch 索引层面的优化， 副本数量、索引数量、分片数量 ElasticSearch查询层面的优化 7 职责分离，全面监控 1 硬件层面的优化1.1 为ES进行 硬件层面的 内存优化：Elasticsearch是一个内存密集型应用，合理分配内存对于Elasticsearch 提高性能至关重要: 确保系统内存有足够的空间用于文件缓存，而不单单是JVM堆内存。 建议将一半的内存分配给Elasticsearch的堆内存，另一半留给操作系统和其他进程。 为了避免垃圾回收（GC）成为瓶颈，建议设置堆内存的最大值为30GB或更小。可以通过修改jvm.options文件来调整堆内存的大小。 总之，ES是比 ...

分布式事务的背景首先说说 分布式事务的背景。 传统单体架构下，所有的功能模块都在一个应用下，所有的代码和 业务逻辑 都在同一个应用下实现，所以保证数据的一致性就很简单，保证相关操作都在同一个本地事务下就可以了。 但是在微服务架构下，将一个应用拆分成了多个独立的服务，每个服务都能有自己的 数据库 ，服务间通信都是通过远程调用实现，实现一个功能可能需要由几个不同的服务来共同实现。 这就会带来一个问题，不同的服务之间无法做到使用同一个事务，这就无法保证数据的一致性了。 这就需要 分布式事务。 最直接、最简单、最粗暴的解决分布式事务的方式， 就是直接使用 Seata。 Seata 分布式事务方案Seata 是一个 开源 的分布式事务解决方案，用于解决分布式系统中的数据一致性问题。 seata中，常用的有两种分布式事务实现方案，AT 及 TCC AT模式主要关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题 TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题 AT模式(业务侵入小)Seata AT模式是基于XA事务演进而来的 ...

基础知识：Spring 两种事务管理方式Spring 支持两种事务管理方式：编程式事务和声明式事务。 事务分为 编程式事务 和声明式事务两种。 编程式事务指在代码中手动的管理事务的提交、回滚等操作，代码侵入性比较强。 声明式事务是通过配置来实现的，不需要在代码中显式地管理事务。 编程式事务是指在代码中显式地开启、提交或回滚事务。这种方式需要在代码中编写事务管理的相关逻辑，比较繁琐，但是灵活性较高，可以根据具体的业务需要进行定制。 声明式事务是通过配置来实现的，不需要在代码中显式地管理事务。这种方式需要在配置文件中声明事务的属性，比如事务的传播行为、隔离级别等。声明式事务的好处是可以将事务管理的逻辑与业务逻辑分离，使得代码更加简洁、清晰，同时也方便了事务管理的统一配置和维护。 在 Spring 中，声明式事务 是基于 AOP 面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低，声明式事务也有两种实现方式。 Spring 提供了两种声明式事务的方式： 基于 XML 配置 基于注解配置。 基于 XML 配置的方式需要在 Spring 配置文件中声明事务管理器和事务通 ...

1.背景介绍数据一致性是分布式系统中的一个重要问题，它涉及到多个节点之间的数据同步和一致性。 数据一致性问题在分布式系统中具有重要的意义。而CAP定理是一个关于分布式系统的一致性模型 。 CAP定理 是 分布式系统的 底层定理， 也是 面试的核心重点。 接下来，带大家来 穿透 CAP定理， 哪些中间件是AP，哪些中间件 是CP，让面试官 口水直流。 2.CAP定理2.1 CAP 猜想/CAP证明/CAP定理CAP 猜想 CAP 定理（CAP theorem）又被称作 布鲁尔定理 ，是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（EricBrewer）在 2000 年的 ACM PODC 上提出的一个猜想。CAP 证明 2002 年，麻省理工学院的赛斯·吉尔伯特（SethGilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。CAP 定理 CAP该定理指出一个 分布式系统 最多只能同时满足 一致性（Consistency） 、可用性（Availability）和分区容错性（Partition t ...

elk（Elasticsearch、Logstash、Kibana）从入门到精通的 学习路线ELK 其实并不是一款软件，而是一整套解决方案，是三个软件产品的首字母缩写 Elasticsearch：负责日志检索和储存 Logstash：负责日志的收集和分析、处理 Kibana：负责日志的可视化 这三款软件都是开源软件，通常是配合使用，而且又先后归于 Elastic.co 公司名下，故被简称为 ELK 1 ELK日志平台介绍ELK指的是Elastic公司下面Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称。 Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称。 1.1 基础日志平台的背景日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。 通常，日志被分散的储存不同的设备上。 如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。 这样是 ...

首先回顾一下：redis 四大统计（基数统计，二值统计，排序统计、聚合统计）的原理 和应用场景尼恩这边的文章都有一个 基本的规则，从最为基础的讲起。 先看看 常见的四大统计。 第1大统计：基数统计基数（Cardinality）是指一个集合中不同元素的数量， 或者说统计一个集合中不重复元素的个数。 简单来说： 基数（Cardinality）就是去除重复后的数的个数 例如，对于一个包含重复元素的集合{1, 2, 2, 3, 4, 4, 4}，其基数为4，即不同元素的个数。 在Redis中，HashSet /bitmap/ HyperLogLog数据结构都能提供 高效的基数统计，而HyperLogLog算法可以在不保存原始数据的情况下快速计算出一个集合的基数。 希音面试：亿级用户 日活 月活，如何统计？（史上最强 HyperLogLog 解读） 第2大统计：二值统计二值统计通常涉及到将数据分为两个类别或状态，比如成功与失败、是与非等，并对这些类别进行计数和分析。 这种统计方法在处理二分类问题时非常常见，比如在质量控制、用户行为分析等领域。 亿级海量数据查重，如何实现 ？ ...

如何判断什么时候可以给大表加索引？随着业务的快速增长，用户中心的用户表user单表数据量越来越大，此时，如果我们业务调整，想给test_user表添加索引，便于提升性能。 或者，通过慢查询日志发现了一条慢SQL，相关业务表随着数据增加已达千万级，需要加索引进行优化查询，想给test_user表添加索引，便于提升性能。 实际上，直接给大表加索引、加字段属于DDL（数据定义语言）操作，很可能会引起锁表，报错Waiting for meta data lock，造成业务崩溃。 任何对MySQL大表的DDL操作都值得警惕，那么如何对大表进行加索引操作？ 简历神僧，45岁老架构师，给大家来要给彻底的解读。 两种索引构建的方式例如，MySQL 在构建索引时，可以使用在线（Online）模式或者离线（Offline）模式。 在线模式（Online DDL）： 这种模式允许在构建索引的同时，数据库可以继续进行读写操作，对业务的影响较小。 但不是所有的存储引擎和数据库版本都支持这种方式。 如果支持，例如在较新的 InnoDB 存储引擎版本中，可以通过设置参数来使用在线模式构建索引。 不过，在线模式可能 ...

先看看 常见的四大统计。 第1大统计：基数统计基数（Cardinality）是指一个集合中不同元素的数量， 或者说统计一个集合中不重复元素的个数。 简单来说： 基数（Cardinality）就是去除重复后的数的个数 例如，对于一个包含重复元素的集合{1, 2, 2, 3, 4, 4, 4}，其基数为4，即不同元素的个数。 在Redis中，HashSet /bitmap/ HyperLogLog数据结构都能提供 高效的基数统计，而HyperLogLog算法可以在不保存原始数据的情况下快速计算出一个集合的基数。 第2大统计：二值统计二值统计通常涉及到将数据分为两个类别或状态，比如成功与失败、是与非等，并对这些类别进行计数和分析。 这种统计方法在处理二分类问题时非常常见，比如在质量控制、用户行为分析等领域。 比如：亿级海量数据查重，如何实现 ？涉及的是四大统计其中的 二值统计 比如：亿级海量数据黑名单 ，如何存储？涉及的也是四大统计其中的 二值统计 第3大统计：排序统计排序统计涉及将数据按照一定的顺序（如升序或降序）进行排列，以便于分析和比较。 排序统计的例子，比如，可以 ...

首先回顾一下：四大统计（基数统计，二值统计，排序统计、聚合统计）的原理 和应用场景这边的文章都有一个 基本的规则，从最为基础的讲起。 先看看 常见的四大统计。 亿级海量数据查重，如何实现 ？涉及的是四大统计其中的 二值统计 亿级海量数据黑名单 ，如何存储？涉及的也是四大统计其中的 二值统计 第1大统计：基数统计基数（Cardinality）是指一个集合中不同元素的数量， 或者说统计一个集合中不重复元素的个数。 简单来说： 基数（Cardinality）就是去除重复后的数的个数 例如，对于一个包含重复元素的集合{1, 2, 2, 3, 4, 4, 4}，其基数为4，即不同元素的个数。 在Redis中，HashSet / HyperLogLog数据结构都能提供 高效的基数统计，而HyperLogLog算法可以在不保存原始数据的情况下快速计算出一个集合的基数。 基数统计的2大类型类型 1：精确计算： 对于较小规模的数据集，可使用数据结构如哈希集合（HashSet）来实现基数统计。 哈希集合利用哈希函数将元素映射到存储位置，其内部会自动处理元素的插入和冲突问题。 当插入一个元素时，哈 ...

MySQL中“where 1=1”的性能影响深究“where 1=1” 这个条件， 非常常见，也非常好用。 但是， 隐藏在背后一个巨大的 性能问题。“where 1=1”在动态 SQL 中的应用WHERE 1 = 1在动态 SQL 场景中经常被使用，很多开发者喜欢在构建动态SQL查询时使用它，因为它可以方便地添加额外的查询条件。 在动态构建 SQL 查询语句时，添加WHERE 1 = 1可以方便地在其后添加其他条件，“1=1” 常被用作where 的 一个条件占位符。 有了 1 = 1，当我们可以动态地添加多个查询条件，不同担心“AND”或“OR”关键字的拼接问题。 例如，在一个 Java 程序中动态构建 SQL 查询： String sql = "SELECT \* FROM table\_name WHERE 1 = 1"; if (condition1) { sql += " AND column1 = value1"; } if (condition2 ...