分布式微服务系统架构第96集：大型跨境电商JVM调优，MongoDB、Elasticsearch (ES)、Cassandra 在查询性能

我是哪吒2025-04-06 19:13

加群联系作者vx：xiaoda0423

仓库地址：webvueblog.github.io/JavaPlusDoc...

1024bat.cn/

方法定义：

arduino 复制代码 
public void handleBiz(List<ConsumerRecord<?, ?> > records, long countTime, String timeStr)
  • records：从 Kafka 消费到的消息列表。
  • countTime：用于记录处理耗时的初始时间戳。
  • timeStr：处理时间字符串，一般为当前时间格式化结果。
1. 遍历 Kafka 消息：
ruby 复制代码 
for (ConsumerRecord<?, ?> record : records) {

对每条消息进行业务处理。

解析 JSON 转为对象：
ini 复制代码 
String value = record.value().toString();

ES 异步写入及耗时记录：

将事件信息写入 ES 异步批处理系统（可能用于后续查询或分析）并记录耗时。

设备响应处理（设备侧上报才响应）：

  • 如果设备上传带有响应信息，并且是 设备端上报，则向设备返回响应；
  • 失败则跳过，等待下次设备重发。

判断是否重复事件（幂等性处理）：

构造唯一标识，并通过 Redis 判断事件是否已经处理，防止因设备重发造成重复操作。

查询事件明细判断是否已经入库（避免重复）：

如果该事件的明细数据已经存在，说明该事件已经完整处理，跳过即可。

校验用户订单：

判断当前用户是否正在进行换电操作（有进行中的订单），如果没有，调用 isReportBlChangeBat 判断是否需要响应，并跳过处理。

总结版对比：

场景/特性 MongoDB Elasticsearch Cassandra
查询速度（通用） ⭐⭐☆（较快） ⭐⭐⭐（超快） ⭐☆（一般）
复杂查询支持 强（文档查询、聚合） 强（全文检索、聚合、打分） 弱（只支持简单查询）
全文搜索 一般（支持，但不强） 非常强（核心优势） 弱（几乎不支持）
实时数据分析 中等 非常快 较慢（非设计目的）
批量写入性能 高 中等 非常高（写入利器）
写入一致性保障 强（支持事务） 弱（可配置） 最终一致性
适合数据结构 文档型（JSON） 文档型（JSON） 表结构（类SQL行列结构）

🔍 场景具体说明

1. MongoDB

  • 优势：

    • 查询灵活：支持字段索引、聚合查询、复杂的 JSON 条件。
    • 写入快，查询也很快（如果有合适索引）。
    • 可支持一定的全文搜索（用 text 索引）。

  • 适用场景：

    • 一般业务系统（订单、用户、配置、日志等）
    • 高并发读写场景
    • 不需要复杂全文检索或海量实时分析的应用
2. Elasticsearch

  • 优势：

    • 全文搜索王者，模糊匹配、打分、分页、排序等功能很强。
    • 聚合分析超快，适合实时 BI、日志分析。
    • 对查询响应时间极其敏感的系统（比如推荐系统、搜索系统）

  • 缺点：

    • 占用资源较多
    • 写入延迟可能较高（非实时一致）

  • 适用场景：

    • 搜索引擎、日志系统（如 ELK）
    • 实时大数据查询分析
3. Cassandra

  • 优势：

    • 分布式写入非常快，适合大规模并发写入。
    • 高可用、最终一致，适合 IoT、监控指标、时序数据。

  • 缺点：

    • 查询支持简单：不能 LIKE、不能 JOIN、不能聚合
    • 所有查询必须走主键或二级索引，否则很慢

  • 适用场景：

    • 写多读少场景：时序数据、传感器数据、指标监控
    • 电信、银行等对可靠性要求高的系统

🚀 查询速度谁最快？

如果单纯比较查询速度：

  • ES最快（针对搜索/聚合查询）
  • MongoDB次之（针对结构化文档）
  • Cassandra最慢（查询能力受限）

但前提是你有没有建好索引、你的查询类型是否适配该数据库的引擎。

📌 举个实际例子：

比如你要处理"换电柜子事件日志"的查询：

  • 需要模糊搜索、关键词查询、时间区间聚合 → 用 ES
  • 需要存储结构化文档+偶尔查询分析 → 用 MongoDB
  • 只需要持续高频写入（比如电量日志）+ 定期批量分析 → 用 Cassandra

写入性能横向对比总结

特性/对比点 MongoDB Elasticsearch Cassandra
写入速度 ⭐⭐☆（快） ⭐⭐（中等） ⭐⭐⭐（非常快）
批量写入效率 高 中 非常高
并发写入能力 强 中 非常强（写入机器）
写入延迟 低 可能有延迟（刷新机制） 极低
写一致性保障 强（可配置事务） 最终一致（不强一致） 最终一致（AP系统）
写放大影响 少 大（Lucene索引刷新） 少
写入容错能力 中 低 非常强（P2P复制架构）

🔍 单点结论：

🥇 写入最快：Cassandra

  • 为什么快？

    • 写入是 append-only（顺序写入磁盘，无需更新原位置）
    • 每次写入都是异步同步到副本（最终一致）
    • 架构天然为高吞吐写入优化，支持百万级写入/秒

  • 适用场景：

    • 海量写入（IoT 数据、日志、传感器）
    • 不要求强一致、写入后延迟可接受的系统
🥈 次快：MongoDB

  • 写入比较快，支持：

    • 文档级别原子性
    • 批量插入性能高
    • 可以通过副本集+分片扩展写入吞吐量

  • 若开启写确认和事务，性能会略降

🥉 最慢：Elasticsearch

  • 为什么慢？

    • 每次写入都要刷新 Lucene 索引（涉及倒排索引、分词等操作）
    • 写入默认不是实时 ，有刷盘机制（refresh_interval 默认 1 秒）

  • 适合"写多、查更频繁"的搜索场景，而不是极致写入

📌 真实写入场景举例

应用场景 推荐数据库 原因说明
IoT 高频数据写入（每秒上万） Cassandra 最终一致性+写入并发强+分布式友好
业务系统记录日志、订单等 MongoDB 支持事务、写入快，结构灵活
日志分析、搜索日志系统 Elasticsearch 写入还可以，但为了搜索、不是写入而优化

🔧 额外 Tips

  • MongoDB 开启 writeConcern=1（默认）写入会非常快，但牺牲一点持久性
  • Cassandra 尽量避免读后写或更新场景（不擅长更新，适合追加写）
  • Elasticsearch 可以通过设置 refresh_interval=-1 临时关闭刷新，提升写入，但数据不可查询

✅ 总结：

写入速度排名（从快到慢） ：
Cassandra > MongoDB > Elasticsearch

ssr 渲染时机 服务器端生成完整HTML，浏览器直接渲染，首屏速度，较快，用户可快速看到内容，Seo 友好性，高，搜索引擎可直接抓取完整内容。

React Native 端开发流程

本篇主要讲解 Taro React Native 端开发流程，React Native 开发前注意事项请看 开发前注意。

Taro3.x 跨端（h5、weapp、rn）开发可参考项目：Taro 跨平台 demo（React Native + Weapp + h5）

Taro React Native APP 开发调试工具，请查看 Taro Playground 项目。

简介​

Taro 移动端的开发基于 Facebook 的开源项目 React Native。选择 React 框架开发的 Taro 项目，经过适配可以编译成 React Native 的 bundle 文件，再通过对应平台的工具可编译为 Android 及 iOS APP。

整体设计如下：

开发前准备​

为了更顺利地进行开发，我们强烈地建议您，先对 React Native 开发进行学习。学习资料可在 React Native 中文网中找到，也可到 React Native 官网中查看。

完成基础知识的学习后，建议上手完成环境搭建，并确保能够顺利运行。环境搭建参考 React Native 中文网的文档 及 React Native 官网的文档。

开发模式​

Taro 开发 React Native APP，提供了两种模式：

  1. 集成模式：JS、iOS、Android 在同一仓库，通过 taro init 生成且选择 react-native 模板的项目，会采用此模式。与 npx react-native init AwesomeProject 生成的项目结构基本一致。入门开发者推荐使用此模式。
  2. 分离模式：JS 代码在一个仓库，iOS 和 Android 代码在另外一个仓库（也称壳工程）。JS 代码可通过 taro init 选择任意模板生成。壳工程代码可 fork Taro Native Shell 项目。

本地开发完Taro项目。想发布到H5和app端，请问是使用yarn build:h5编译成H5发布，然后使用yarn build:rn --platform ios编译成app发布吗

配置说明：

  1. 堆设置
    o -Xms:初始堆大小
    o -Xmx:最大堆大小
    o -XX:NewSize=n:设置年轻代大小
    o -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
    o -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
    o -XX:MaxPermSize=n:设置持久代大小
  2. 收集器设置
    o -XX:+UseSerialGC:设置串行收集器
    o -XX:+UseParallelGC:设置并行收集器
    o -XX:+UseParalledlOldGC:设置并行年老代收集器
    o -XX:+UseConcMarkSweepGC:设置并发收集器
  3. 垃圾回收统计信息
    -XX:+PrintGC
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -Xloggc:filename
    "
  4. 并行收集器设置
    -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
    -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
    -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
  5. 并发收集器设置
    -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
    -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
    （4）

参数解释：

-Xms3072m -Xmx3072m

针对JVM堆的设置，通过-Xms -Xmx限定其最小、最大值

-Xmn1024m设置年轻代大小为1024m

整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小（perm）。

-Xss768k 设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

-XX:PermSize=512m -XX:MaxPermSize=512m

持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4

-XX:+UseConcMarkSweepGC

CMS收集器也被称为短暂停顿并发收集器。它是对年老代进行垃圾收集的。CMS收集器通过多线程并发进行垃圾回收，尽量减少垃圾收集造成的停顿。CMS收集器对年轻代进行垃圾回收使用的算法和Parallel收集器一样。这个垃圾收集器适用于不能忍受长时间停顿要求快速响应的应用。

-XX:+UseParNewGC对年轻代采用多线程并行回收，这样收得快；

-XX:+CMSClassUnloadingEnabled

如果你启用了CMSClassUnloadingEnabled ，垃圾回收会清理持久代，移除不再使用的classes。这个参数只有在 UseConcMarkSweepGC 也启用的情况下才有用。

-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能；

-XX:+UseCMSInitiatingOccupancyOnly

标志来命令JVM不基于运行时收集的数据来启动CMS垃圾收集周期。而是，当该标志被开启时，JVM通过CMSInitiatingOccupancyFraction的值进行每一次CMS收集，而不仅仅是第一次。然而，请记住大多数情况下，JVM比我们自己能作出更好的垃圾收集决策。因此，只有当我们充足的理由(比如测试)并且对应用程序产生的对象的生命周期有深刻的认知时，才应该使用该标志。

-XX:CMSInitiatingOccupancyFraction=68

默认CMS是在tenured generation(年老代）占满68%的时候开始进行CMS收集，如果你的年老代增长不是那么快，并且希望降低CMS次数的话，可以适当调高此值；

-XX:+UseParNewGC：对年轻代采用多线程并行回收，这样收得快；

-XX:HeapDumpPath

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:/usr/aaa/dump/heap_trace.txt

上面的的参数打Heap Dump信息

" -XX:+HeapDumpOnOutOfMemoryError

此参数可以控制OutOfMemoryError时打印堆的信息

cms的概念：

CMS收集器也被称为短暂停顿并发收集器。它是对年老代进行垃圾收集的。CMS收集器通过多线程并发进行垃圾回收，尽量减少垃圾收集造成的停顿。CMS收集器对年轻代进行垃圾回收使用的算法和Parallel收集器一样。这个垃圾收集器适用于不能忍受长时间停顿要求快速响应的应用。CMS采用了多种方式尽可能降低GC的暂停时间,减少用户程序停顿。停顿时间降低的同时牺牲了CPU吞吐量 。这是在停顿时间和性能间做出的取舍，可以简单理解为"空间(性能)"换时间。

JVM（Java Virtual Machine）监控是对Java应用程序运行时的性能、资源使用情况、垃圾回收（GC）、线程活动等进行观察和分析的过程。常用于诊断性能瓶颈、内存泄漏、线程死锁等问题。

下面是常见的JVM监控方法与工具：

一、常见监控指标

  1. 堆内存使用情况（Heap Memory Usage）
  2. 非堆内存（Metaspace, Code Cache等）
  3. GC次数和时间
  4. 线程数和线程状态
  5. 类加载数量
  6. CPU使用率
  7. 磁盘I/O和网络I/O

二、常用监控工具

1. JConsole
  • JDK自带的图形化工具。
  • 启动：jconsole
  • 功能：查看内存、线程、类加载、GC等信息。
2. VisualVM
  • 比JConsole更强大，支持插件。
  • 启动：jvisualvm
  • 支持远程监控、Heap Dump分析、CPU/Memory Profiler。
3. jstat
  • 命令行工具，监控JVM性能。
  • 示例：jstat -gc <pid> 1000
  • 用于实时查看GC行为、类装载信息等。
4. jstack
  • 打印线程栈信息。
  • 示例：jstack <pid>
  • 常用于分析线程死锁、阻塞等问题。
5. jmap
  • 查看堆内存使用情况、生成heap dump。
  • 示例：jmap -heap <pid>，jmap -dump:live,format=b,file=heap.hprof <pid>
6. Java Flight Recorder (JFR) & Mission Control
  • JDK内置的高性能监控工具。
  • 适合线上生产环境，开销小。
  • 用JMC打开 .jfr 文件进行分析。
7. Prometheus + Grafana + JMX Exporter
  • 适合微服务、分布式架构。
  • JMX Exporter以HTTP方式暴露JVM指标，Prometheus收集，Grafana可视化展示。

三、在线生产监控建议

  1. 开启JMX端口
    允许远程连接JConsole、VisualVM、JMC。
  2. 定期Dump分析（如OOM后）
    使用-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=/path/to/heapdump.hprof
  3. 监控报警机制
    比如：堆内存使用率超过80%报警、Full GC频繁报警等。
ini 复制代码 
==== Memory Usage ====
Heap Memory: init = 532676608(520192K) used = 45293464(44231K) committed = 510656512(498688K) max = 7572291584(7394816K)
Non-Heap Memory: init = 2555904(2496K) used = 14640968(14297K) committed = 15138816(14784K) max = -1(-1K)

==== Garbage Collectors ====
Name: PS Scavenge
Collection Count: 0
Collection Time: 0ms
Name: PS MarkSweep
Collection Count: 0
Collection Time: 0ms

==== Threads ====
Live Threads: 6
Peak Threads: 6
Total Started Threads: 6

==== JVM Runtime Info ====
Uptime: 1072ms
JVM Name: Java HotSpot(TM) 64-Bit Server VM
JVM Vendor: Oracle Corporation
JVM Version: 25.351-b10

1. 🧾 方法区（Method Area）

  • 作用：用于存储类的结构信息，如类名、访问修饰符、字段、方法、常量池、静态变量、JIT 编译后的代码等。

  • 特点：

    • 所有线程共享
    • 也称为 "永久代（PermGen）"（JDK 8 之前）或 "元空间（Metaspace）"（JDK 8 之后）

2. 🛏️ 堆（Heap）

  • 作用：存储所有对象实例、数组。是垃圾回收器的主要管理区域。

  • 特点：

    • 所有线程共享

    • 分代管理：新生代（Young Gen）、老年代（Old Gen）

      • 新生代进一步细分为 Eden 区、Survivor 区（S0 和 S1）

    • GC 主要在这一区域发生

3. 🌀 虚拟机栈（JVM Stack）

  • 作用：每个线程私有，存储方法调用的栈帧（局部变量表、操作数栈、动态链接、返回地址等）

  • 特点：

    • 每调用一个方法就会创建一个栈帧
    • 栈帧中包含该方法的所有执行信息
    • 会抛出栈溢出异常（StackOverflowError）

4. 🧬 本地方法栈（Native Method Stack）

  • 作用：与 JVM Stack 类似，但专用于处理 Native 方法（用 C/C++ 写的本地方法）

  • 特点：

    • 每个线程私有
    • 抛出 StackOverflowError 或 OutOfMemoryError

5. 🧭 程序计数器（Program Counter Register）

  • 作用：记录当前线程正在执行的字节码指令的地址（即程序执行位置）

  • 特点：

    • 每个线程私有
    • 是唯一不会发生 OOM 的区域
相关推荐
白云~️1 小时前
uniappx 打包配置32位64位x86安装包
运维·服务器·github
白总Server2 小时前
多智能体系统的中间件架构
linux·运维·服务器·中间件·ribbon·架构·github
_一条咸鱼_3 小时前
揭秘 Android TextInputLayout：从源码深度剖析其使用原理
android·java·面试
_一条咸鱼_3 小时前
揭秘！Android VideoView 使用原理大起底
android·java·面试
_一条咸鱼_3 小时前
深度揭秘！Android TextView 使用原理全解析
android·java·面试
_一条咸鱼_3 小时前
深度剖析：Android Canvas 使用原理全揭秘
android·java·面试
_一条咸鱼_3 小时前
深度剖析！Android TextureView 使用原理全揭秘
android·java·面试
_一条咸鱼_3 小时前
揭秘！Android CheckBox 使用原理全解析
android·java·面试
热门推荐
01西电B测-计算机网络综合实验(含验收问题)02KGG转MP3工具|非KGM文件|解密音频03从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑04Coze扣子平台完整体验和实践（附国内和国际版对比）05YOLOv8入门 | 重要性能衡量指标、训练结果评价及分析及影响mAP的因素【发论文关注的指标】06DeepSeek各版本说明与优缺点分析07yolov10来了！用yolov10训练自己的数据集（原理、训练、部署、应用）08yolov8，yolo11，yolo12 服务器训练到部署全流程 笔记09我决定放弃搞 Java 了10最新 Kubernetes 集群部署 + flannel 网络插件（保姆级教程，最新 K8S 版本）