程序猿的三高：高并发、高可用、高性能_高并发 高性能 高可用

一、高并发指标

高并发是现在互联网分布式框架设计必须要考虑的因素之一，它是可以保证系统能被同时并行处理很多请求，对于高并发来说，它的指标有：

响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间。

吞吐量：吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。

秒查询率：秒查询率是指每秒响应请求数，和吞吐量差不多。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

二、处理高并发的方案

1：系统拆分

        将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：redis缓存

        大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发，没问题的。所以可以考的虑考虑项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)

        可能还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，那高并发绝对搞挂系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。

        所以该用mysql还得用mysql，用MQ，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是可以的。

4：分库分表

        可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离

        这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

二. 高性能

1.什么是高性能呢？

        高性能是指程序处理速度非常快，所占内存少，cpu占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统发并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和IO密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量，内存，IO等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。

2.怎么样提高性能呢？

避免因为IO阻塞让CPU闲置，导致CPU的浪费

避免多线程间增加锁来保证同步，导致并行系统串行化

免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上

（1）、使用位图提升查询性能

（2）、使用布隆过滤器解决缓存穿透。

（3）、限流算法 计数器：redis可以实现滑动窗口算法，漏桶算法 和 令牌桶都可以通过消息队列实现，虽然google的guawa可以实现限流，但是单机限流，分布式环境下无法达到目的。

（4）、RocketMQ性能提升方法。

（5）、redis主从复制，哨兵模式，集群

（6）、mysql读写分离 ：binlog日志，分库分表，分库分表带来的问题

（7）、消息队列的可靠性：生产者发送重试，消息队列同步复制，异步刷盘，消费者重试消费，到死信队列，重复消费，增加一个去重表。每次先插入去重表。

（8）、多级缓存

（9）、熔断降级，sentinel熔断降级策略 慢点用 异常比例 异常数

            流量控制：QPS流量控制 直接拒绝 warm up 匀速排队。

            高级设置里有根据调用方限流，链路限流，只限流自特定链路的请求，关联限流， 写操作频繁时，对读操作进行限流。生产环境中使用sentinel。

三. 高可用

1.高可用是什么？

        高可用通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。高可用注意如果使用单机，一旦挂机将导致服务不可用，可以使用集群来代替单机，一台服务器挂了，还有其他后备服务器能够顶上。或者使用分布式部署项。

2.redis的高可用的集群方案

         Redis单副本

         Redis多副本（主从）

         Redis Sentinel（哨兵）

         Redis Cluster

         Redis自研。