5、缓存优化方案

我们在用缓存的时候，不管是Redis或者Memcached，基本上会通用遇到以下三个问题：

• 缓存穿透

• 缓存并发

• 缓存失效
   

注：上面三个图会有什么问题呢？

我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。

那这种问题有什么好办法解决呢？

要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值。
 

比如，"key" , “&&”。

在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。

有时候如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。

我现在的想法是对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。

这种情况和刚才说的预先设定值问题有些类似，只不过利用锁的方式，会造成部分请求等待。

引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。

那如何解决这些问题呢？

其中的一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

我们讨论的第二个问题时针对同一个缓存，第三个问题时针对很多缓存。

总结来看：

6、程序容错优化方案
 

在这一块我要先举一个程序的例子说明一下什么才是容错，先看程序：

注：那么如果service层的方法调用dao层的方法，一旦数据插入失败，那么这种异常处理的方式是容错吗？

把异常给吃掉了，在service层调用的时候，虽然没有打印报错信息，但是这能是容错吗？

所谓容错是指在故障存在的情况下计算机系统不失效，仍然能够正常工作的特性。

我们拿使用缓存来作为一个案例讲解，先看一个图：

这是一个最简单的图，应用服务定期从redis中获取配置信息，可能会有朋友认为这样已经很稳定了，但是如果Redis出现问题呢？可能会有朋友说，Redis会是集群，分片或者主从，确保不会出现问题。

其实我是这样认为的，虽然应用服务程序尽量的保持轻量级是不错的，但是不能因此而把希望全部寄托在中间组件上面，换句话说，如果此时的Redis是单点，那么后果会是什么样的，那么随着大量的并发请求到来的时候，程序中会报大量的错误，同时正常的流程也不能进行下去了业务也可能由此而中断。

那么在此种场景下我的解决方案是，要把缓存的使用分级别，有的缓存同步要求时效性非常高，比如支付限额配置，在后台修改完成以后前台立刻就能够获得感知，并且能够成功切换，这种情况只能实时的从Redis中获取最新数据，但是每次获取完最新的数据后都可以同步更新本地缓存，当单点的Redis挂掉后，应用程序至少还能从本地读取信息而不至于服务瞬间挂掉。有的缓存对时效性要求不高，允许有一定延迟，那么在这种情况下我采用的方案是，利用本地缓存和远程缓存相结合的方式，如下图所示：
 

方案一：

这种方式通过应用服务器的Ehcache定时轮询Redis缓存服务器更同步更新本地缓存，缺点是因为每台服务器定时Ehcache的时间不一样，那么不同服务器刷新最新缓存的时间也不一样，会产生数据不一致问题，对一致性要求不高可以使用。

方案二：

通过引入了MQ队列，使每台应用服务器的Ehcache同步侦听MQ消息，这样在一定程度上可以达到准同步更新数据，通过MQ推送或者拉取的方式，但是因为不同服务器之间的网络速度的原因，所以也不能完全达到强一致性。基于此原理使用Zookeeper等分布式协调通知组件也是如此。

7、部分项目拆分不彻底

拆分前

注：一个Tomcat中布署多个应用war包，彼此之间互相牵制在并发量非常大的情况下性能降低非常明显。

拆分后

注：拆分前的这种情况其实还是挺普遍，之前我一直认为项目中不会存在这种情况但是事实上还是存在了。解决的方法很简单，每一个应用war只布在一个tomcat中，这样应用程序之间就不会存在资源和连接数的竞争情况，性能和并发能力提交较为明显。

8、因基础平台组件功能不完善导致性能下降

先看一段代码：

注：首先我们先不说这段代码的格式如何如何，先看功能实现，使用Future来做超时控制，这是为何呢？原因其实是在我们调用的Dubbo接口上面，因为是Dubbo已经经过二次封装，结果把自带的timeout给淹沫了，程序员只能通过这种方式来控制超时，可以看到这种用法非常差劲，对程序性能造成一定的影响。

9、如何快速定位程序性能瓶颈

我相信在定位程序性能问题的时候，大家有很多种办法，比如用jdk自带的命令，如Jcmd，Jstack，jmap，jhat，jstat，iostat，vmstat等等命令，还可以用VisualVM，MAT，JRockit等可视化工具，我今天想说的是利用一个最简单的命令就能够定位到哪段程序可能存在性能问题，请看下面介绍：

一般我们会通过top命令查看各个进程的cpu和内存占用情况，获得到了我们的进程id，然后我们将会通过pstack命令查看里边的各个线程id以及对应的线程现在正在做什么事情，分析多组数据就可以获得哪些线程里有慢操作影响了服务器的性能，从而得到解决方案。示例如下：

由此可以判断出来在LWP 30222这个线程产生了性能问题，执行时间长达31.4毫秒的时间，再观察无非就是下面的几个语句出现的问题，只需要简单排查就知道了问题瓶颈。

10、关于索引的优化

• 组合索引的原则是偏左原则，所以在使用的时候需要多加注意

• 索引的数量不需要过多的添加，在添加的时候要考虑聚集索引和辅助索引，这二者的性能是有区别的

• 索引不会包含有NULL值的列
  只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

• MySQL索引排序
  MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

• 使用索引的注意事项
  以下操作符可以应用索引:
  大于等于
  Between
  IN
  LIKE 不以%开头

   

  以下操作符不能应用索引：

  NOT IN

  LIKE %_开头

• 索引技巧
  同样是1234567890，数值类型存储远比字符串节约存储空间。
  节约存储就是节约IO，减少IO就是提升性能
  通常对数字的索引和检索要比对字符串的索引和检索效率更高。

11、使用Redis需要注意的一些点

• 在增加key的时候尽量设置过期时间，不然Redis Server的内存使用会达到系统物理内存的最大值，导致Redis使用VM降低系统性能

• Redis Key设计时应该尽可能短,Value尽量不要使用复杂对象。

• 将对象转换成JSON对象（利用现成的JSON库）后存入Redis。

• 将对象转换成Google开源二进制协议对象（Google Protobuf，和JSON数据格式类似，但是因为是二进制表现，所以性能效率以及空间占用都比JSON要小；缺点是Protobuf的学习曲线比JSON大得多）

• Redis使用完以后一定要释放连接，如下图示例：

​

不管是返回到连接池中还是直接释放掉，总之就是要将连接还回去。

在接下来的第二篇文章中我们将介绍系统的降级、限流，还有监控的一些方案。敬请期待！