企业官网建设流程全解析

1. 为什么说集群、分片、MySQL同步是ES入门的三个坎

如果你刚把ElasticSearch的单机版跑起来，往里面塞了几万条测试数据，用Kibana画了两张图表，然后觉得自己已经会了——那我要泼一盆冷水：离能上生产还差得远。单机ES就像一个摆在实验室里的玩具发动机，能转、能看，但你真要拿它去带一整辆车上路，第一脚油门它就会给你脸色看。

我见过太多人死在这三件事上：

第一，集群。明明多起几个节点就完事，结果节点之间互相找不到、脑裂、分片不迁移、集群状态变红——运维噩梦全来了。

第二，分片。很多人把ES当成一个超大号的MySQL来用，建好索引就不管了，结果数据量一上来，查询从毫秒级掉到秒级，还不知道问题出在分片设计上。

第三，同步MySQL数据。业务库在MySQL里躺着，搜索需求一来，产品经理说"把数据库里的数据都同步到ES里吧"，你老老实实写代码一把梭——然后全量同步跑了三天三夜，内存爆了，增量同步又频繁丢数据，被DBA追着骂。

这篇东西就是围绕这三个坎写的。我会用一套完整的实战过程把它们挨个讲透：怎么搭一个三节点的集群、分片和副本到底怎么分配才合理、怎么把MySQL的数据稳定地同步进ES。内容偏操作向，但每一步我都会解释"为什么这么干"，因为只给命令不给理由的文章我从来不看，我相信你也不愿意看。

适合这几类人：ES入门一段时间、正在准备上生产的朋友；被集群莫名其妙的坑折磨过的运维同学；以及被"MySQL数据同步ES"逼到想转行的后端开发。如果你是纯零基础，建议先能把单机ES跑起来再来读，不然有些地方你会跟不上。

2. 集群的核心机制：节点角色、发现与脑裂

在动手搭建之前，我强烈建议你先花十分钟理解集群的几个底层概念。这一步省不得，因为我见过太多人配置写得一模一样，结果第一个节点启动就把后面几个节点挤下线了——根因就是没搞懂节点角色。

2.1 节点角色：谁在干活，谁在管事儿

ES集群里的每个节点都可以承担不同角色，角色是通过配置文件里的node.roles指定的。理解角色的关键是：ES不是一个"所有节点地位平等"的系统，它内部有明确的分工。

三个核心角色你必须知道：

• master节点：负责集群层面的管理操作，比如创建删除索引、分配分片、维护集群状态。注意，master不参与文档的索引和查询——别指望把master当存储节点用。
• data节点：真正存数据、执行查询和写入的节点。这是集群里最累的角色，CPU、内存、磁盘压力都在它身上。
• coordinating节点：只接收请求、路由转发、汇总结果，不存数据。小集群用不上，但大集群里它很有价值。

默认情况下，一个节点同时承担所有角色，也就是node.roles为空。这对小集群没问题，但如果你打算长期跑，建议把职责拆开。我在配置三节点集群时，通常会让三个节点都设置成可选master和数据节点，这样既省机器又能保证高可用。如果你的机器资源足够，可以考虑单独加一个 coordinating 节点来承接查询压力。

2.2 节点发现：为什么三个节点互相找不到

ES集群的节点之间靠"发现机制"（discovery）找到彼此。早期版本用的是多播，现在主流是单播，也就是在配置文件里告诉节点"你的同伴们住在哪些地址"。

# elasticsearch.yml discovery.seed_hosts: - 192.168.1.10 - 192.168.1.11 - 192.168.1.12

这段配置的意思是：节点启动后，尝试连接这三个地址，把它们加入自己所属的集群。这里有个容易被忽略的坑：必须加上初始主节点的配置，否则集群永远选不出master，日志里全是"master not discovered yet"的报错。

cluster.initial_master_nodes: - node-1 - node-2 - node-3

注意，这个配置只对集群首次启动有用。首次选举出master之后，正常情况就不需要它了，但如果你在集群运行中加了新节点，新节点上依然是靠discovery.seed_hosts找到master并加入集群。所以从习惯上我建议每次都保留这两段配置，省得以后扩节点时还要去改。

2.3 脑裂问题：一个集群分裂成两个"独立王国"

脑裂（split brain）是分布式系统里最经典、也最致命的故障之一。简单说，由于网络抖动或GC暂停，部分节点和master临时失联，这些节点会认为master挂了，于是自己发起新一轮master选举——结果就是集群里同时出现两个master，各管一摊分片，数据写入时就可能发生冲突，等你发现的时候数据已经乱了。

ES解决脑裂的手段是**法定人数（quorum）**机制：一个节点想成为master，必须获得超过半数可投票节点的支持。具体配置是：

discovery.zen.minimum_master_nodes: 2 # 老版本 cluster.election.maximum_master_nodes: 2 # 新版本

这个数值算起来很简单：（master候选节点数 / 2）+ 1。在三节点集群里就是2，在五节点集群里就是3。我见过有人图省事直接给3个节点配了1，结果就是集群一抖动就重新选主，整个集群抖成筛子。这是ES集群运维里最经典的坑，没有之一。

注意：从ES 7.x开始，minimum_master_nodes被默认配置为自动维护，日常不用手动改。但了解它的原理仍然必要，因为当你手工扩展或缩容节点时，自动配置不一定符合你的预期，理解背后的决策逻辑能让你在日志里看到投票结果时心里有底。

3. 三节点集群搭建实操：从配置到验证的完整流程

理论部分就到这，接下来动手。我的环境是三台CentOS 7的虚拟机，内存各8G，磁盘各100G，IP分别是192.168.1.10/11/12。ES版本用7.10.0（这个版本稳定，坑少，社区资料也多）。

3.1 环境准备：JDK版本和系统参数缺一不可

ES 7.10要求JDK 11以上。推荐用ES自带的JDK（tar包解压后里有jdk目录），省得自己配Java环境变量，还能避开系统JDK版本太新或太旧导致的莫名故障。

# 解压ES tar -zxvf elasticsearch-7.10.0-linux-x86_64.tar.gz mv elasticsearch-7.10.0 /usr/local/es

然后必须修改系统参数，因为ES对系统资源的要求很苛刻，默认配置肯定会被它嫌弃：

# /etc/security/limits.conf 追加 esuser soft nofile 65536 esuser hard nofile 65536 esuser soft nproc 4096 esuser hard nproc 4096 # /etc/sysctl.conf 追加 vm.max_map_count=262144 sysctl -p # 使其生效

max_map_count这个参数是针对内存映射区的限制，ES底层大量使用mmap，默认值太低会导致启动时报"max virtual memory areas vm.max_map_count [65530] is too low"。我在这上面吃过亏，配好三个节点重启后才发现有一个节点没生效，排查了半天。

还有一点：绝对不能用root用户跑ES。ES出于安全考虑，明确拒绝root启动。创建一个专用用户：

useradd esuser chown -R esuser:esuser /usr/local/es su esuser

3.2 核心配置逐项解析

这是最关键的一步，直接给配置，然后解释每一项的用途：

# node-1 的 elasticsearch.yml cluster.name: my-es-cluster node.name: node-1 node.roles: [master, data, ingest] path.data: /data/es/data path.logs: /data/es/logs network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - 192.168.1.10 - 192.168.1.11 - 192.168.1.12 cluster.initial_master_nodes: - node-1 - node-2 - node-3

• cluster.name：集群的名称，三个节点必须完全一致，否则它们会认为彼此属于不同集群，永远合不到一起。
• node.name：节点标识，必须唯一。建议起有意义的名字，不然排查问题时满屏node-1、node-2你也分不清谁是谁。
• path.data和path.logs：数据目录和日志目录。千万别放在默认的/tmp下，因为Linux会周期性清理/tmp目录，我就见过有人的数据目录被清掉后，集群直接瘫痪，不得不从备份恢复。
• network.host：这里写0.0.0.0表示监听所有网卡。注意，如果这里配了非loopback地址，ES会自动切换到生产模式，对bootstrap检查等要求会更严格，这时候你的系统参数要是没配好就起不来。
• transport.port：节点间内部通信端口，默认9300。这个是集群内部通信用的，和HTTP端口9200要区分开。

第2台和第3台配置一样，只需改node.name为node-2、node-3。配置别的不用动。

3.3 启动集群和验证

确认配置无误后，在三个节点分别执行启动命令：

# 这里提权是ES推荐的启动方式，可以先验证一下配置有没有问题 /usr/local/es/bin/elasticsearch -d -p /tmp/elasticsearch.pid

-d表示后台运行，-p用来记录PID文件，后面停止服务时可以用kill $(cat /tmp/elasticsearch.pid)。

日志在/data/es/logs/my-es-cluster.log里，启动出错时先看这个。最常见的两个问题：

1. 报failed to bind to [9300]——检查一下端口占用，或者三台机器的防火墙没放行9300端口。
2. 报master not discovered——三种情况：cluster.initial_master_nodes没配置或写错节点名、discovery.seed_hosts的地址写错、三台机器的cluster.name不一致。

启动完验证：

curl -X GET "http://192.168.1.10:9200/_cluster/health?pretty"

理想的返回是：

{ "cluster_name": "my-es-cluster", "status": "green", "number_of_nodes": 3, "active_primary_shards": 0, "active_shards": 0 }

看到status为green、number_of_nodes为3，说明集群心脏在跳。如果你看到的是yellow也别慌，可能是索引没有副本分片导致的，后面创建索引时加上副本就能变绿。

3.4 集群故障转移验证：手动杀节点看ES的反应

集群搭完了，不做一次故障演练就说不过去了。我的习惯是：kill掉一个data节点，观察集群能不能自动把分片迁移到别的节点上，这也顺手检验一下分片设计得对不对。

kill -9 $(cat /tmp/elasticsearch.pid) # node-1

然后每隔几秒查询一次集群健康状态：

curl -X GET "http://192.168.1.11:9200/_cluster/health?pretty"

你会看到状态先是yellow——因为有一个节点掉线了，部分副本分片暂时不能分配。与此同时，集群会自动把掉线节点上的分片在其他节点上重新创建。等几十秒到几分钟（取决于分片大小和磁盘速度），状态会回到green。

这个过程的细节非常值得关注：master节点重新分配分片时，I/O 和 CPU 都会明显拉高。这直接证明了为什么集群规划时至少要留出30%-40%的余量，不能把磁盘打到90%以上——否则节点故障后的自动迁移可能因为资源不足而失败，故障就真的成灾难了。

4. 分片机制拆解：索引设计的底层逻辑

集群搭好之后，下一个绕不开的问题是分片。很多人把分片当成了一种"存储选项"，想用就用、不想用就不用。实际上，分片是ES数据分布和并行的根本机制，理解它直接决定你的索引设计质量。

4.1 分片到底是什么：主分片和副本分片的关系

ES的一个索引，逻辑上就是一个完整的"表"，物理上却被切成若干块，每一块就是一个主分片（primary shard）。每个主分片还可以有若干副本分片（replica shard），副本是主分片的完整拷贝，作用是高可用和分摊查询压力。

这里的关键点是：

• 写入请求只会到主分片，由主分片负责，同步给副本。
• 读请求可以走副本，所以副本越多，查询吞吐量越大。
• 主分片数量在索引创建后不可修改——想改只能重建索引，这一点你必须趁早想清楚。

用生活里的类比：主分片好比一个仓库里的实体货架，副本分片是这些货架的拍照备份。实体货架的数量决定了仓库能摆多少货，并且一旦定了就不能改；而照片备份没了可以再洗，不影响仓库容量，只是取货时会可能出现等照片的情况。

4.2 分片数量怎么定：公式、权衡和反直觉的结论

主分片数量到底设多少？我建议套这个思路来算：

1. 预估你的最终数据总量。
2. 单个分片的数据量建议控制在20GB到50GB之间。这个是经验值范围，低于这个可以，超出这个查询和merge压力会显著上升。
3. 主分片数量 = 预估数据总量 / 单分片合理容量。

比如你预估最终数据有200GB，那主分片设5到10个都可以。不要贪多，分片太多了反而拖慢查询；也不要太少，少了数据挤在一起性能上不去。

有一个反直觉的结论需要强调：主分片多不代表查询快。查询时ES会把请求广播到所有分片并行执行，再合并结果。分片过多会导致调度开销变大、合并结果变慢，反而让查询变慢。很多人一上来就建30个主分片，数据量却只有几GB，就是典型的过犹不及。

副本分片的数量则按需调整：读多写少的场景可以设为2或更多，写入密集的场景设1就够——否则写一条数据要同步给多个副本，写入延迟会被拉高。

4.3 分片不均匀：数据倾斜的实战案例

我干过一件蠢事，说出来给大家当反面教材。

当时给日志索引设置了10个主分片，不设副本，跑了一周后发现某几个分片涨到40GB，另外几个只有10GB。查询延迟从100毫秒涨到1秒多，ESSlowlog里全是超时记录。

排查过程是这样的：先看每个分片的大小——

curl -X GET "http://192.168.1.10:9200/_cat/shards/my-index?v&h=index,shard,prirep,store,node"

输出里明显能看到store列的数值差距。再逐个节点看磁盘占用，确认不是某个节点机器问题，而是分片本身的数据量分配不均。

问题根子在于我的索引使用了自定义的路由字段（routing），而路由值的分布本来就不是均匀的——某些用户的数据量天然就多。ES默认按_id哈希路由可以整套避开这个问题，但我当时为了按用户隔离查询，强行指定了路由键，于是把一个分片变成了热点。

解决方向是重建索引，优化路由策略，比如换成按用户ID的哈希值再取模，并配合冷热节点架构来转移压力，保证数据尽量均匀分布。所以你现在问我分片设计的原则，我只会说一句话：不要让任何单一维度天然形成热点。

4.4 分片的生命周期：rollover与ILM

当你开始认真对待分片，迟早会碰到索引的滚动管理问题。ES提供了一整套索引生命周期管理（ILM）机制，核心是让索引按条件自动滚动：

PUT _ilm/policy/log_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50gb", "max_age": "30d" } } } } } }

这个策略的意思是：当索引超过50GB或者存在超过30天后，自动创建一个新索引，把写入流量切过去。

配合索引模板使用，新索引自动套用分片数和别名设置：

PUT _index_template/log_template { "index_patterns": ["logs-*"], "template": { "settings": { "number_of_shards": 5, "number_of_replicas": 1, "routing.allocation.include.size": "hot" } } }

这套机制的好处是：你不再需要手动预估索引规模，也不用操心"数据满了怎么办"。我建议所有日志类场景、时序类场景都直接上ILM，省心。但要注意，ILM只负责滚动，不负责删除——冷数据删不删、怎么删，你需要自己在策略里配delete阶段。

5. MySQL数据同步到ES：三种方案选型与实战

集群和分片都搞清楚了，现在来到第三个坎：把MySQL的数据同步进ES。这可能是日常开发里最接地气的需求——你有一张用户表、订单表、文章表，需要提供站内搜索或复杂筛选。

5.1 三种主流方案对比：Logstash、Canal、自研同步

先说说市面上的答案。围绕"MySQL同步到ES"，主流方案大致三条路：

我个人的建议是：初期或者数据量不大，直接上Logstash。它配置简单，能快速见效。等业务量上来、对实时性要求高了，再演进到Canal方案。

理由有两个：第一，Logstash的定时轮询对数据量小的表（百万级以内）完全够用，同步延迟能控制在分钟级；第二，它的全量+增量逻辑天然支持，不需要你从头写状态维护的代码。

5.2 实战：用Logstash把MySQL表全量+增量同步进ES

这块我直接给出一个能复制的流程。我的测试场景是一张文章表（article），大约80万行数据，结构简化如下：

CREATE TABLE `article` ( `id` bigint(20) NOT NULL, `title` varchar(255) DEFAULT NULL, `content` text, `status` tinyint(4) DEFAULT '1', `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第一步，准备Logstash的配置文件。新建mysql-sync.conf：

input { jdbc { jdbc_driver_library => "/usr/local/logstash/lib/mysql-connector-java-8.0.22.jar" jdbc_driver_class => "com.mysql.cj.jdbc.Driver" jdbc_connection_string => "jdbc:mysql://192.168.1.100:3306/testdb?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai" jdbc_user => "es_sync" jdbc_password => "your_password" statement => "SELECT id, title, content, status, update_time FROM article WHERE update_time > :sql_last_value" use_column_value => true tracking_column => "update_time" tracking_column_type => "timestamp" schedule => "* * * * *" last_run_metadata_path => "/data/logstash/conf/last_run" } }

几个关键点我要逐条讲：

• tracking_column指定增量同步的追踪字段，通常是记录更新时间的update_time。use_column_value设为true表示使用这个字段的值来判断哪些行需要同步。
• schedule是Cron表达式，"* * * * *"表示每分钟执行一次。如果你不需要太实时，改成5分钟一次也可以。
• last_run_metadata_path保存上一次同步到的update_time值。这样每次重启Logstash后增量位置不会丢。
• 这里有一个大坑：如果当天更新了很多数据，且update_time用的是MySQL的datetime类型，跨时区时容易差8小时。连接串里要显式指定serverTimezone=Asia/Shanghai，两边都用同一时区。

第二步，配置filter和output：

filter { mutate { rename => { "id" => "article_id" } remove_field => ["@version", "@timestamp"] } } output { elasticsearch { hosts => ["192.168.1.10:9200", "192.168.1.11:9200", "192.168.1.12:9200"] index => "article_index" document_id => "%{article_id}" user => "elastic" password => "changesme" } }

document_id直接映射MySQL主键，这是幂等更新的关键：同一行数据重新同步时会覆盖，不会产生重复文档。这个设计一定要坚持。

第三步，首次跑全量。上面那段增量配置是跑不了全量的，因为update_time > :sql_last_value在第一次执行时只能把update_time大于1970年1月1日的数据捞出来，值太小了也可能导致全量捞不出来。我这里的处理是额外准备一个全量配置文件，或者干脆在第一次全量后把last_run_metadata_path文件里的值初始化成你想要的全量起点：

# 初始化last_run，只同步近7天数据 echo "--- 2024-01-01 00:00:00" > /data/logstash/conf/last_run

全量同步时我建议分页拉取，避免一次性加载80万行把Logstash的堆撑爆。JDBC input支持自定义SQL，也可以配合jdbc_page_size参数控制批次。

jdbc_paging_enabled => true jdbc_page_size => 5000

5.3 又一个坑：MySQL的delete操作Logstash感知不到

这是Logstash方案最大的硬伤。业务里删了MySQL的一行数据，ES里那条文档不会自动消失——你搜出来的结果就成了"查无此源"的脏数据。

我实际项目里的处理方法是：业务层做软删除。表里加一个deleted字段，删除时不真删，只把这个字段置为1。同步时SQL里加上条件：

SELECT id, title, content, status, update_time FROM article WHERE update_time > :sql_last_value AND deleted = 0

同时在ES侧建立针对删除的兜底清理：如果deleted字段为1，同步时把文档删除：

filter { if [deleted] == 1 { mutate { add_field => { "[@metadata][action]" => "delete" } } } }

如果你没法改表结构，就得考虑Canal方案了。Canal通过解析binlog能拿到删除主键，然后调用ES删除接口，这是真正“物理删除实时同步”的唯一成熟路径。

5.4 进阶：Canal + Kafka + Logstash的实时同步架构

当数据量和实时性要求同时上来时，我推荐这套组合：Canal监听MySQL的binlog变更，发送到Kafka，Logstash消费Kafka消息写入ES。

架构看起来多了一层，但每个组件各司其职，压力分散。Canal负责实时捕获数据库变化，Kafka负责削峰和缓冲，Logstash只做格式转换和ES写入。数据库变更的洪峰来了，Kafka能兜住，不会压垮ES。

Canal部署后的一个核心配置样例：

# canal.properties canal.serverMode = kafka kafka.bootstrap.servers = 192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092

Logstash对应配置：

input { kafka { bootstrap_servers => "192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092" topics => ["article_topic"] codec => "json" } } output { elasticsearch { hosts => ["192.168.1.10:9200", "192.168.1.11:9200"] index => "article_index" document_id => "%{id}" } }

这套架构部署起来比Logstash单机方案复杂得多，但换来的是秒级延迟和更强的抗流量能力。我的经验是：数据量超过千万级，或者业务对搜索结果的时效性要求是分钟以内，直接考虑Canal方案，别犹豫。Logstash轮询方案的延迟和能力上限，到那个规模一定会让你回头重写。

6. 整个链路的性能排查思路

最后写一点实战排查经验。三节点集群、分片、MySQL同步，这些都跑起来之后，你一定会遇到"到底哪里慢了"的问题。这个问题的排查思路，很多人没走对。

先定一个总原则：从端到端切割，沿着链路逐段打点。一次完整的ES写入链路由生产端、网络、ES集群三部分组成，任何一段出问题都会表现为"写入慢"。

我从一个真实的线上问题说起。当时项目反馈：ES写入高峰期频繁超时，日志里时不时报Elasticsearch health check failed。

我当时是按这个顺序排查的：

第一步，确认集群本身状态。调用_cluster/health看状态和未分配分片数量，再调_cat/nodes?v看每个节点的CPU、堆内存使用率和负载。这里有个细节：在几毫秒内连续调用几次，观察数据变化幅度而不是只看单次值——单次采样看不出问题，趋势才有效。

第二步，检查写入线程池是否堆积。ES的写入是异步线程池模型：

curl -X GET "http://192.168.1.10:9200/_cat/thread_pool/write?v&h=node_name,name,active,queue,rejected"

rejected这个值特别关键——如果大量请求被拒绝，说明写入压力已经超过集群承载能力，再查下去就是找瓶颈在哪一台节点上了。

第三步，看慢日志。ES有专门的索引慢日志：

PUT /article_index/_settings { "index.search.slowlog.threshold.query.warn": "500ms", "index.search.slowlog.threshold.fetch.warn": "300ms", "index.indexing.slowlog.threshold.index.warn": "500ms" }

设置完之后，超过阈值的请求会记录在logs/es_index_search_slowlog.log里。通过慢日志里的shard编号，你能定位是哪个分片慢。如果集中在一两个分片，大概率是数据倾斜；如果所有分片都慢，就要看磁盘I/O和CPU了。

第四步，区分磁盘问题还是CPU问题。在节点上执行iostat -x 1看util参数，如果持续90%以上，磁盘就是瓶颈。同时看ES的JVM GC日志——如果出现频繁的Full GC，那瓶颈在堆内存。磁盘慢和CPU过载是两个完全不同的调优方向，前者要扩磁盘或降副本，后者要增加节点或调大批量写入窗口。这个区分做错，调优就是一个瞎忙的大动作。

关于排查，我把一个常用的定位顺序总结成这四步，遇到问题按顺序来，基本都能找到方向：

1. 集群健康（是否红/黄）
2. 节点负载（CPU、内存、I/O是否失衡）
3. 线程池和队列（写入、搜索线程是否有拒绝）
4. 分片分布与慢日志（是否热点集中）

7. 一些能直接落地的小建议

写到最后，串一串这三件事在实际项目中应该怎么配合。

版本选择上，ES 7.10是我目前比较推荐的稳定版本，和MySQL同步的JDBC驱动选8.0.x及以上，Logstash版本要和ES大版本对齐，不要一个7.x一个8.x混着用，配置格式会有兼容问题。

三节点集群的分片设计，我给个默认起步值：日志类数据用3主分片+1副本，业务类数据用5主分片+1副本，然后靠ILM滚动控制单分片大小在50GB以内。这套配置在大多数场景下是安全的选择，后续容量涨了再扩副本比改分片容易得多。

MySQL同步的演进路径，我建议按业务时效性来决策：时效性要求不在于分钟级（比如商品搜索、文章搜索），直接Logstash定时同步，一个月后再考虑要不要升级；时效性要求在秒级（比如订单状态的实时可见、运营后台的实时报表），一开始就上Canal。架构选择回头改的代价很大，一开始就选对路最省钱。

最后我想说：ES不是一个"配置完就完事"的东西，它是一个需要持续观察、持续调优的系统。集群搭好了只是开始，分片和同步的设计同样要跟着数据量成长不断修正。你踩的那些坑——不管是节点互相找不到、分片数据倾斜，还是同步丢数据——最后都会变成你对这套系统真正的理解。你搭的每一个集群，都会成为你下一套集群的经验底气，这就是这个领域积累的真相。