20190103生产问题--持续更新

上午9点，数据库CPU达到100%，导致数据库服务超时，不可用

    查询原因：个人用户权限表大概7000万数据，9点业务高发期，而且每一次操作都会验证权限。大量的并发被挂起，导致雪崩，  1、而平时不会出现的原因是有缓存，而且昨晚上游系统下发数据导致缓存全部被清空。

2、个人用户权限太大，一次查询可能会查过上万条数据

3、有一张表，10万数据，6个优先级，需要6个sql进行union查询，导致查询慢，CPU高 

       后来进行优化，分成6个单独的sql查询，优先级高的有值，就不会继续查，否则继续查SQL.

       上线后，的确针对这个sql没有了超时等情况，cpu在80%以下，没收到报警，很开心

但其他查询：例如这个权限查询总是超时，而且多个服务都瘫痪，

最后：发现数据库qps高峰在6000左右，拆分后的sql执行次数一天在100万次左右，于是提高数据库连接数800到1200，尽管CPU到了90%左右，但服务都可以访问了，怀疑是qps太高，但连接数不够，导致服务不可用

 

2019.1.8：补充1

      预加载所有的数据到缓存后，但依然数据库对应sql访问量不减，无奈之下甚至开始r怀疑edis是否取值成功

      后来突然想到：存在的放在redis,那不存在的还是要查6次数据库啊，

     于是针对这个处理，数据库查不到的，放到redis里,value默认0，于是就可以无需查询数据库了，全部从redis走

2019.1.8：补充2

       教训：一定要仔细关注mysql的慢查询语句，针对执行多次的语句，看一下它的查询条件，重点关注。我们就是自认为后年的参数是N个查询条件中的一个，没有去关注查询条件。后来发现 就是这个sql ,把他对应的值放到缓存里后，系统立马快了很多。

2019.1.9:补充

     QPS不变，但数据库CPU在保持在5%，和前端时间的90%天差地别

    计划解决策略：

                      1、下发数据时，修改zk值，为防止白天加载热点数据到redis会影响白天业务，特于晚上定时任务：预加载用户权限热点数据，修改完毕后，修改zk值

                      2、分库存储（按用户分库），毕竟数据量太大

                      3、预加载的数据：过期时间加随机值