8、合理使用内存
众所周知，关系型数据库DB查询底层是磁盘存储，计算速度低于内存缓存，缓存DB与业务系统连接有一定的调用耗时，速度低于本地内存；但是从存储量来看，内存存储数据容量低于缓存，长期持久化的数据建议放DB存在磁盘中，设计过程中考虑好成本和查询性能的平衡。
说到内存，就会有数据一致性问题，DB数据和内存数据如何保证一致性，是强一致性还是弱一致性，数据存储顺序和事务如何控制都需要去考虑，尽量做到用户无感知。
9、做好数据压缩
很多中间件对数据的存储和传输采用了压缩和解压操作，减少数据传输中的带宽成本，这里对数据压缩不再做过多的介绍，想提的一点是高并发的运行态业务，要合理的控制日志的打印，不能够为了便于排查，打印过多的JSON.toJSONString(Object)，磁盘很容易被打满，按照日志的容量过期策略也很容易被回收，更不方便排查问题；因此建议合理的使用日志，错误码仅可能精简，核心业务逻辑打印好摘要日志，结构化的数据也便于后续做监控和数据分析。
打印日志的时候思考几个问题：这个日志有没有可能会有人看，看了这个日志能做什么，每个字段都是必须打印的吗，出现问题能不能提高排查效率。
10、Hbase热点key问题
Habse的存储结构如下:Table在行的方向上分割为多个HRegion，HRegion是HBase中分布式存储和负载均衡的最小单元，即不同的HRegion可以分别在不同的HRegionServer上，但同一个HRegion是不会拆分到多个HRegionServer上的。HRegion按大小分割，每个表一般只有一个HRegion，随着数据不断插入表，HRegion不断增大，当HRegion的某个列簇达到一个阈值（默认256M）时就会分成两个新的HRegion。
HBase 中的行是按照 Rowkey 的字典顺序排序的，这种设计优化了 scan 操作，可以将相关的行以及会被一起读取的行存取在临近位置，便于scan。Rowkey这种固有的设计是热点故障的源头。热点的热是指发生在大量的 client 直接访问集群的一个或极少数个节点(访问可能是读，写或者其他操作）。
大量访问会使热点 Region 所在的单个机器超出自身承受能力，引起性能下降甚至 Region 不可用，这也会影响同一个 RegionServer 上的其他 Region，由于主机无法服务其他 Region 的请求，这样就造成数据热点(数据倾斜)现象。
所以我们在向 HBase 中插入数据的时候，应优化 RowKey 的设计，使数据被写入集群的多个 region，而不是一个，尽量均衡地把记录分散到不同的 Region 中去，平衡每个 Region 的压力。
常见的热点Key避免的方法: 反转，加盐和哈希
- 反转：比如用户ID2088这种前缀，以及BBCRL开头的这种相同前缀，都可以适当的反转往后移动。
- 加盐： RowKey 的前面增加一些前缀，比如时间戳Hash，加盐的前缀种类越多，才会根据随机生成的前缀分散到各个 region 中，避免了热点现象，但是也要考虑scan方便
- 哈希：为了在业务上能够完整地重构 RowKey，前缀不可以是随机的。 所以一般会拿原 RowKey 或其一部分计算 Hash 值，然后再对 Hash 值做运算作为前缀。
总之Rowkey在设计的过程中，尽量保证长度原则、唯一原则、排序原则、散列原则。
