高并发系统设计原则

转：https://www.cnblogs.com/diegodu/p/9244955.html

功能特性有选择

对于一个需要承受高并发的接口，在功能上尽量不涉及一些难以缓存和预热的数据。比如用户维度的数据，缓存命中率低，会带来高并发的sql查询。
示例：
1、秒杀时，不同用户有不同的秒杀内容和优惠，每个用户都会进行一次sql查询。
2、多个优惠活动时，用户仅能参加一种为参加过的活动。

解决方式：
①转换数据维度，秒杀资格以userId为key缓存命中率低，可以以秒杀活动id为key。
②将个性化数据功能在业务流程上后移。优惠活动，不在页面显示用户的优惠，而在创建订单时才显示用户可以参加的优惠活动。

处理信息量要少

我们写业务代码的时候都有对应的业务对象，它们都存在一定的业务范围之内，比如类目、地区、日期等自身相关的维度（也就是筛选）尽可能的增加筛选的条件，减少传输的业务对象的数量。
比如影院活动，至少按照影片、日期、影院筛选，传输的业务对象则会大大减少。若在加上合适的分表，则会增加并发量，加快接口的响应。

根据业务特性选择实现方式

平时涉及到的业务，总有属于它的特性，比如实时性要求多高，数据一致性要求多高，涉及什么维度的数据，量有多大等等，我们要根据这些特性来选择实现的方案。

示例：若是一些统计数据，不必要每次查询都遍历数据，可以离线生成一张统计表，并且缓存到服务器。

合适选择和调用缓存

缓存是业务对抗高并发非常重要的一个环节，合理选择缓存的类型和调用缓存的时机非常重要。
存储效率：内存 <= ehcache < redis <= memcached < mysql
ehcache ：分布式开源缓存、具有内存和磁盘存储
redis ：key-value存储系统、支持主从同步
memcached ：分布式缓存服务器

常用的缓存

1. varnish，可以作为反向代理，缓存一些资源，例如可以把struts，freemarker动态生成的页面存储起来，达到直接挡掉到达web服务器的请求。
2. ehcache，主要存储在当前机器内存中，存取非常快，缺点是内存有限，各台机器内存中各存一份，失效时间不一致，数据就会出现不一致，一般用来缓存不常变化，且缓存个数较少的数据。
3. memcached缓存，kv分布式缓存集群，可扩展性好，可以存储个数较多的缓存对象，也可以承接高流量的访问，读取缓存时远程连接，一般耗时也在零点几到几ms不等。
4. redis，nosql，是内存的kv存储，可以做为缓存使用，也可以持久化，它的性能和memcached相近。而redis最大的特点是一个data-structure store，这时redis官网首页介绍redis的第一句话，它可以保存list，hash，set，sorted set等数据结构，使用时和memcached区别是，它不用将数据取到客户端再做逻辑判断，而是可以直接在redis服务器上完成操作，比如查看某个元素是不是一个范围内，队列的长度有多长等。redis可以用来做分布式服务器的进程间的通信，比如我们经常有需要分布式锁的场景，控制同一个用户发券的并发等。

根据业务需要选择了合适类型的缓存后，还要合理去使用。 虽然说缓存是为了抵挡数据库的流量而生，本身性能非常强大，但仍然是受到缓存服务器性能甚至服务器网卡流量的限制的，不合理的使用比如单个key对应的缓存对象过大、一次读取中缓存key数量过多、短时间内频繁更新缓存等都是系统的隐患、并发越高时就越能体现。