1. 从零到一eleme 项目上线到底在做什么很多人看到“上线 eleme 项目”这几个字第一反应是“外卖平台那不是早就成熟得不能再成熟的东西了吗”。但真正做过这类项目的人心里都清楚一个外卖类业务系统的上线从来不是把代码往服务器上一扔就完事。它背后牵扯的是高并发读写、分布式事务、数据库分库分表、流量入口负载均衡这一整套工程化能力。我这次接手的就是一个典型的 eleme 风格项目——用户端下单、商家端接单、骑手端配送、后台管理四端联动日均订单量在压测阶段就冲到了六位数。关键词里出现的MySQL、Mycat、Java、LVS这四个词基本勾勒出了这个项目的技术骨架。Java 负责业务逻辑MySQL 扛数据存储Mycat 做分库分表中间件LVS 顶在最前面做四层负载均衡。这套组合在中小型互联网公司里非常常见原因很简单成熟、资料多、招人好招、出问题能查到解决方案。但“常见”不等于“简单”恰恰是因为用的人多踩过的坑才格外密集。这篇文章适合谁看如果你正在准备一个类似规模的 Java 项目上线或者你已经在用 Mycat 做分库分表但总觉得哪里不对劲又或者你对 LVS 的理解还停留在“配个 VIP 就完事”的阶段那这篇内容应该能帮你省下不少通宵排查的时间。我会把上线过程中真实遇到的选型逻辑、配置细节、排查链路和那些文档里不会写的经验一条一条摊开来讲。需要先说明一点下面涉及的具体参数和配置是基于我这次项目的实际环境CentOS 7 JDK 17 MySQL 8.0 Mycat 1.6 LVS/DR 模式总结出来的你的环境如果不同数值需要相应调整但排查思路和设计逻辑是通用的。2. 技术选型背后的取舍为什么是这套组合2.1 Java 作为业务层的现实考量选 Java 做业务层在这个项目里几乎没有争议。团队里大部分人都是 Java 背景Spring Boot 生态成熟遇到问题社区里一搜一大把。但真正让我在选型阶段纠结的是JDK 版本。项目立项时 JDK 17 已经是 LTS 版本但团队里有人担心第三方依赖跟不上。我当时的判断是新项目没有历史包袱直接上 JDK 17避免以后再做版本迁移。这里有个细节值得单独拎出来说。编译的时候如果遇到java: 警告: 源发行版 17 需要目标发行版 17这类提示说明 Maven 或 Gradle 里的 source/target 配置和实际 JDK 不一致。很多人以为这只是警告可以忽略但在某些依赖注入框架下这种不一致会导致运行时出现莫名其妙的UnsupportedClassVersionError。我的做法是在pom.xml里显式锁定properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target maven.compiler.release17/maven.compiler.release /properties用release参数而不是单独的 source/target能确保编译时校验 API 兼容性避免用了高版本 API 却在低版本运行的问题。2.2 MySQL 版本选择与安装方式的坑MySQL 的版本选择上我最终定了 8.0。原因有三个一是窗口函数和 CTE 在订单统计类查询里太香了二是 8.0 的默认字符集是 utf8mb4省去了以前改字符集的麻烦三是官方对 8.0 的维护周期还很长。安装方式上我强烈建议不要用 yum 默认源里的 MySQL。很多 Linux 发行版自带的 MySQL 版本老旧而且配置文件路径和官方文档对不上排查问题时会被带偏。正确做法是去 MySQL 下载官网拿官方社区的 RPM 包或者通用二进制包。如果图省事用 Docker 跑也可以但生产环境我不推荐把数据库放在容器里I/O 性能和持久化都有隐患。安装完之后有个必做的步骤设置默认值相关的参数。比如订单表里很多状态字段需要默认值 0建表时就要写清楚DEFAULT 0而不是依赖应用层传值。我见过太多因为字段没设默认值插入时又没传结果 MySQL 在严格模式下直接报错的情况。sql_mode里如果开了STRICT_TRANS_TABLES这种问题会立刻暴露反而是好事。2.3 Mycat 承担分库分表的角色定位单表数据量一旦超过千万级别查询性能下降会非常明显。eleme 这类业务的订单表增长极快所以分库分表是必须的。Mycat 作为中间件对应用层屏蔽了分片细节SQL 写起来和单库差不多这是它最大的优势。但 Mycat 不是银弹。它的核心问题是跨分片查询和分布式事务。如果分片键选得不好一个简单的关联查询就会变成全分片扫描性能比单库还差。我这次选的分片键是user_id因为绝大多数查询都是围绕用户维度展开的。商家维度的查询则通过异构索引表来解决牺牲一点写入性能换查询效率。2.4 LVS 在最前面挡流量的理由LVS 工作在四层性能极高单台就能扛几十万并发连接。相比 Nginx 这种七层负载均衡LVS 不解析应用层协议开销小得多。eleme 项目的入口流量先经过 LVS再转发到后端的 Nginx 集群Nginx 再做七层路由到具体的 Java 服务。这种两层负载的架构既保证了入口的高吞吐又保留了七层路由的灵活性。LVS 有三种模式NAT、DR、TUN。我选的是DR 模式因为它的响应数据不经过 LVS 回程LVS 只处理请求转发压力小吞吐高。代价是 LVS 和后端服务器必须在同一个二层网络里这个在机房内网环境下不是问题。3. 环境搭建阶段最容易翻车的几个环节3.1 MySQL 安装后连不上的经典报错装完 MySQL 第一次启动十有八九会遇到这个报错error 2002 (hy000): cant connect to local mysql server through socket /tmp/mysql.sock这个报错的意思是客户端找不到 socket 文件。原因通常有两个一是 MySQL 服务根本没启动成功二是 socket 文件路径和客户端默认查找路径不一致。排查顺序应该是先systemctl status mysqld看服务状态如果服务是活的再用find / -name *.sock找到实际的 socket 路径然后在连接时用-S参数指定或者修改/etc/my.cnf里的socket配置让两边对齐。我踩过的一个更隐蔽的坑是MySQL 数据目录的权限不对导致服务启动时无法写入但日志里只报了一个很模糊的错误。解决办法是确认datadir目录的属主是mysql用户权限是 750。这个细节在官方安装文档里写得很清楚但很多人装的时候用 root 一路操作最后忘了改权限。3.2 Java 环境变量配置的细节Java 环境变量配置看起来是最简单的事但配置不当会导致一些奇怪的问题。JAVA_HOME必须指向 JDK 的根目录而不是bin目录。PATH里要把$JAVA_HOME/bin加进去。配置完之后一定要source /etc/profile并且重新开一个终端验证因为有些 shell 会缓存旧的 PATH。还有一个容易被忽略的点如果服务器上装了多个 JDK 版本alternatives命令管理的默认版本可能和你以为的不一样。用which java和java -version双重确认别只看环境变量。3.3 Mycat 的 schema.xml 与 server.xml 配置逻辑Mycat 的配置核心在两个文件schema.xml定义逻辑库、逻辑表和分片规则server.xml定义用户和系统参数。我见过最常见的配置错误是把分片规则写在了错误的位置或者dataNode和dataHost的对应关系搞混。一个实用的排查技巧Mycat 启动后用mysql -h127.0.0.1 -P8066 -umycat_user -p连上去执行show datanode和show datasource能直接看到后端 MySQL 的连接状态。如果某个 dataNode 显示未连接问题一定出在dataHost里的连接串或账号密码上。分片规则的选择上我用了mod-long做用户维度的取模分片简单可靠。但要注意取模分片在扩容时需要重新分布数据所以分片数量要提前规划好。我这次定了 8 个分片按当前业务增速够用两年。3.4 LVS DR 模式的网络配置要点LVS DR 模式最容易出错的地方在ARP 抑制。因为 LVS 和后端服务器都配置了同一个 VIP如果不做 ARP 抑制后端服务器会响应 VIP 的 ARP 请求导致流量直接打到后端而绕过 LVS。解决办法是在后端服务器的回环接口上配置 VIP并设置arp_ignore和arp_announce参数echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce这四个参数的含义分别是只回答目标 IP 是本机 IP 的 ARP 请求、使用最佳本地地址发送 ARP、对所有接口生效。配置完之后用ip addr确认 VIP 只出现在 lo 接口上用arping从其他机器测试 VIP 的 MAC 地址应该是 LVS 服务器的。4. 上线过程中的真实排查链路4.1 订单写入偶发超时从应用日志追到 Mycat上线第二天监控报警显示订单写入接口偶发超时P99 延迟从 200ms 飙到了 3s。应用日志里只看到java.sql.SQLException: Timeout没有更多信息。我的排查顺序是这样的第一步确认是应用层还是数据库层的问题。在应用服务器上用mysql客户端直连 Mycat手动执行一条插入语句发现同样偶发超时。这就排除了应用代码的问题。第二步登录 Mycat 服务器用show connection查看当前连接数发现连接池几乎被打满。再看show threadpool发现后端 MySQL 的响应时间确实变长了。第三步登录后端 MySQL用show processlist查看当前执行的 SQL发现有几条全表扫描的查询在跑。这些查询来自商家端的报表功能没有走分片键导致 Mycat 把查询广播到了所有分片。定位到根因后解决方案有两个一是给报表查询加缓存二是把报表数据同步到独立的汇总表。我选了后者因为报表对实时性要求不高用定时任务每五分钟汇总一次就够了。4.2 LVS 转发正常但后端收不到请求这个问题更隐蔽。LVS 的ipvsadm -Ln显示转发规则正常连接数也在涨但后端 Nginx 的访问日志里没有对应的请求记录。这种情况基本可以断定是ARP 问题或者回程路由问题。我先检查了后端服务器的 ARP 参数确认配置正确。然后抓包分析在 LVS 服务器上tcpdump看到请求确实转发到了后端但在后端服务器上抓包却看不到。这说明数据包在二层就被丢弃了。最后发现是交换机上做了端口隔离LVS 和后端服务器虽然在同一网段但二层不通。联系网络组调整交换机配置后问题解决。这个案例给我的教训是LVS 的问题不全是 LVS 本身的配置问题网络层面的限制同样会导致转发失败。排查时一定要用抓包工具确认数据包的实际流向不要只盯着配置文件。4.3 MySQL 连接池配置与 Mycat 的配合应用层的数据库连接池用的是 HikariCP初始配置的maximumPoolSize是 20。上线后发现高峰期连接不够用但调大到 50 之后Mycat 那边开始报连接数超限。这是因为 Mycat 对后端 MySQL 的连接池是独立的应用层连接数放大后Mycat 到 MySQL 的连接也会相应增加。最终的配置方案是应用层 HikariCP 的maximumPoolSize设为 30Mycat 的maxCon设为 100后端 MySQL 的max_connections设为 500。这三个数值的关系是应用实例数 × 30 要小于 Mycat 的 maxCon 总和Mycat 的 maxCon 总和要小于 MySQL 的 max_connections。留出足够的余量避免任何一个环节成为瓶颈。另外usessl和sslmode这两个参数在 JDBC 连接串里要明确设置。内网环境通常不需要 SSL设成useSSLfalsesslmodeDISABLED可以减少握手开销。但如果你的 MySQL 强制要求 SSL那就得把证书配好否则连接会直接被拒绝。5. 分库分表之后那些绕不开的麻烦5.1 跨分片查询的三种应对策略分片之后跨分片查询是最大的痛点。我总结了三种应对策略按优先级排列第一种避免跨分片查询。这是最理想的方案。设计阶段就把分片键选好让绝大多数查询都能带上分片键。比如订单查询永远带user_id这样 Mycat 能直接路由到单个分片。第二种使用异构索引表。对于必须按其他维度查询的场景建一张索引表把查询维度和分片键的映射关系存起来。比如按商家 ID 查订单先查索引表拿到user_id再用user_id去查订单表。索引表本身也可以分片分片键就是商家 ID。第三种使用全局表。对于数据量小、更新频率低的表比如城市字典、配置表可以在每个分片上都存一份。Mycat 的全局表功能会自动同步这些数据查询时直接路由到本地分片效率很高。5.2 分布式事务的妥协方案跨分片的写操作涉及分布式事务这是分库分表最棘手的问题。强一致性方案比如 XA 事务性能损耗太大不适合高并发场景。我最终采用的是最终一致性方案核心的订单创建走单分片保证强一致跨分片的库存扣减和积分变更通过消息队列异步处理配合本地消息表保证可靠性。具体做法是订单创建成功后往本地消息表插入一条待处理消息然后由定时任务扫描消息表发送到消息队列。下游服务消费消息后执行库存扣减成功后回调确认。如果消费失败消息会重试直到成功或达到重试上限后进入死信队列人工处理。这个方案牺牲了实时一致性但换来了高吞吐和可用性。对于 eleme 这类业务用户下单后库存扣减延迟几百毫秒是完全可以接受的。5.3 分片扩容时的数据迁移前面提到取模分片扩容麻烦这里展开说一下应对方案。如果一开始就预见到数据增长可以用一致性哈希或者预分片的方式。预分片就是一开始就分足够多的片比如 64 片但初期只部署 8 个物理库每个物理库承载 8 个逻辑分片。扩容时只需要把逻辑分片迁移到新的物理库不需要重新计算分片键。我这次因为时间紧用了简单的取模分片但预留了扩容方案在 Mycat 里配置了rule.xml的mod-long规则分片数写成了变量。扩容时修改分片数然后用 Mycat 自带的迁移工具做数据重分布。这个过程需要停机所以安排在凌晨低峰期执行。6. 性能调优与监控的实战经验6.1 MySQL 参数调优的几个关键项MySQL 8.0 的默认参数偏保守生产环境需要调整。我重点调了这几个参数默认值调整值调整理由innodb_buffer_pool_size128M物理内存的 60%缓存数据和索引减少磁盘 I/Oinnodb_log_file_size48M1G减少日志切换频率提升写入性能max_connections151500配合连接池避免连接被拒innodb_flush_log_at_trx_commit12牺牲一点持久性换写入性能sync_binlog1100减少 binlog 同步频率innodb_flush_log_at_trx_commit设成 2 意味着事务提交时日志写入操作系统缓存而不是直接刷盘。如果服务器断电可能丢失最后一秒的事务。对于订单系统这个风险需要评估。我的做法是核心订单表所在的库保持 1其他库设成 2。6.2 Mycat 的性能监控指标Mycat 自带了一套监控命令通过 9066 管理端口可以查看。我常用的几个show sysparam查看系统参数show sql.sum查看 SQL 执行统计show connection查看当前连接show heartbeat查看后端心跳状态其中show sql.sum最有用能看到哪些 SQL 执行次数多、耗时长。我通过这个命令发现了一条没有走分片键的查询优化后整体 QPS 提升了 30%。6.3 LVS 的连接数监控与调优LVS 的性能瓶颈通常在连接跟踪表。ip_vs模块的conn_tab_size默认是 4096高并发下不够用。可以在加载模块时指定更大的值modprobe ip_vs conn_tab_size65536另外ipvsadm -Ln --stats能看到每个虚拟服务的连接数和流量统计。如果发现某个后端服务器的连接数明显偏高说明负载均衡算法需要调整。我用的默认的轮询算法在长连接场景下会导致分配不均后来改成了最少连接算法。7. 上线之后才明白的几个道理第一个体会是压测环境和生产环境的差异永远比你想象的大。压测时用的是模拟数据查询模式单一生产环境的查询模式千奇百怪。上线后第一周我每天花最多时间的事情就是看慢查询日志一条一条优化。第二个体会是监控比调优更重要。调优是事后补救监控是事前预警。我在上线前搭了一套完整的监控体系包括 MySQL 的慢查询、Mycat 的连接数、LVS 的转发量、Java 应用的 GC 情况。这套监控在问题发生前就给了我好几次预警避免了故障扩大。第三个体会是文档里不会写的才是真正值钱的。比如 Mycat 在分片键值分布不均时会出现数据倾斜这个在官方文档里只有一句话带过但实际影响很大。我的解决办法是在分片键前面加一个随机前缀把数据打散。这个技巧是从一个老同事那里学来的比任何文档都管用。最后分享一个排查问题时的小习惯每次遇到问题先别急着改配置先用tcpdump或者strace确认实际发生了什么。我见过太多人凭直觉改了一堆参数结果问题没解决反而引入了新问题。数据包和系统调用不会骗人它们告诉你的才是真相。