系统设计

数据库自增
数据量泄露风险
数据库写压力大，故障后不可用并发性不好
UUID 生成
太长，不易于存储；无序查询效率低
snowflake 雪花算法 bitint(64bit)作为 id 生成类型，划分多段
Redis生成
适用生成流水号，例如：订单号=日期+当日自增长号，每天在 Redis 中生成一个 Key，使用 INCR 进行累加；
集群可使用多个 key，如三个主从 key1 初始化1，key2 初始化2，key3 初始化3，都以步长为3进行 INCR 操作，随机到某一主从，集群分摊压力

分布式，增加服务器数量
- 反向代理层使用 DNS 轮询进行水平扩展 - 站点使用 nginx 进行水平扩展 - 服务层使用服务连接池进行水平扩展 - 数据库使用哈希的方式进行水平扩展

线程池的线程数量不是越多越好，在性能压测中，我们经常能看到随着并发（线程数）的增加，QPS也会随着增加，但到了一定的阈值之后，QPS可能不增反降低。过多的线程意味着过多的内存开销和上下文切换。根据

QPS = 并发数/平均响应时间

当响应时间由于CPU开销大于1的时候，QPS就会增加变缓甚至下降。

所以做性能压测的意义是根据最大的QPS找到最佳的线程数和找出其他影响性能的问题。

一般情况下，服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量

不是把服务器大部分的内存都分给堆就是好事，除了Java虚拟机本身内存，应用还会用到一些本地内存，比如创建线程的时候，JVM没回创建一个Thread对象，同时创建一个操作系统线程，系统线程用的是系统的内存。

如果给 JVM 分配的内存越多，那么能用来创建系统线程的内存就会越少，越容易发生 unable to create new native thread。所以，JVM 内存不是分配的越大越好。

a.堆OOM，调整 -Xmx 大小；
b.本地内存 OOM，压测线程创建过多占满内存，减少线程池最大线程数，减小堆内存。
c.扩展：栈溢出（比如递归）；
- 线程请求深度大于虚拟机深度，StackOverflowError - 虚拟机扩展时无法申请到足够内存，OutOfMemoryError

如果具有满足一下两个条件的对象：
1）对象是可达的。即在有向图中，存在通过达到该对象，GC 不会回收。
2）对象的无用的。即程序以后不会再使用这些对象。

那么这些对象是无有，但是占用着内存空间，并且不会被 GC 回收这就是所谓的内存泄漏。
如果内存泄漏非常严重的话，最终会导致内存溢出。 - OOM 异常 - 内存持续上升 - 频繁 Full GC