关于技术选型

---

一：分布式缓存架构

1.1:缓存概念：存储在计算机上的一个原始数据复制集，以便于访问,用于加快读写速度

1.2:缓冲概念:一个buffer，类似漏斗，在内存空间中预留了一定的存储空间，这些存储空间用来缓冲输入或输出的数据，这部分预留的空间就叫做缓冲区,用来缓冲上下游数据

1.3:可以用来做缓存的:CPU 缓存,操作系统缓存,数据库缓存,JVM 编译缓存,CDN 缓存,代理与反向代理缓存,前端缓存,应用程序缓存,分布式对象缓存都可以用来做缓存

1.4:缓存命中率(比如十次查询九次能够得到正确结果，那么它的命中率是 90%了),指标:缓存键集合大小(用于定位),缓存可使用内存空间(体现缓存数量),缓存对象生存时间(TTL,存在时长)

1.5:代理缓存相关:(代理缓存,反向代理缓存,多层反向代理缓存,内容分发网络（CDN）,CDN 同时配置静态文件和动态内容,浏览器对象缓存,本地对象缓存构建分布式集群,远程分布式对象缓存,Memcached 分布式对象缓存)

1,6:基于虚拟节点的一致性 Hash 算法

1.7:看下介质数据访问延迟时间(纳秒为单位)

1.8:不合理使用缓存的情况

1.8.1:频繁修改的数据：这种数据如果缓存起来，由于频繁修改，应用还来不及读取就已失效或更新，徒增系统负担。一般说来，数据的读写比在2:1以上，缓存才有意义

1.8.2:没有热点的访问：缓存使用内存作为存储，内存资源宝贵而有限，不能将所有数据都缓存起来，如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问不是集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了

1.8.3:数据不一致与脏读：一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的，但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存，不过也会带来更多系统开销和事务一致性的问题。因此数据更新时通知缓存失效，删除该缓存数据，是一种更加稳妥的做法。

1.9:计算机科学中只有三件事最困难:缓存失效，命名事物，计数错误

缓存雪崩：缓存是为了提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到应用程序的处——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大部分的数据访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃的时候，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况，被称作缓存雪崩，发生这种故障，甚至不能简单的重启缓存服务器和数据库服务器来恢复网站访问

缓存预热：缓存中存放的是热点数据，热点数据又是缓存系统利用 LRU（最近最久未用）算法对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间，在这段时间，系统的性能和数据库负载都不太好，那么最好在缓存系统启动的时候就把热点数据加载好，这个缓存预加载手段叫做缓存预热（warm up）。对于一些元数据如城市地名列表、类目信息，可以启动时加载数据库中全部数据到缓存进行预热

缓存穿透：如果不恰当的业务、或者恶意攻击持续高并发的请求某个不存在的数据，因为缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大的压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其 value 值为 null），并设定一个较短的失效时间。

---

二:同步异步架构与消息队列

2.1.1:同步:一条线，耗时高,

2.1.2:异步:开线程耗时少,等回调或不用回调

2.2.1:消息队列,更好的伸缩性,削峰填谷,解耦合,失败隔离和自我重试修复

2.2.2:主要 MQ 产品比较

• RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟悉 Erlang 的同学而言不便于二次开发和维护。（49M）

• ActiveMQ 影响比较广泛，可以跨平台，使用Java开发，对Java比较友好。（27M）

• RocketMQ 是阿里推出的一个开源产品，也是使用Java开发，性能比较好，可靠性也比较高。（35M）

• Kafka ，LinkedIn 出品的，Scala 开发，专门针对分布式场景进行了优化，因此分布式的伸缩性会比较好。（63M）

---

三:负载均衡相关

1.HTTP 重定向负载均衡(用户调用一个相当于跑两次)

2.DNS 负载均衡(先去dns服务器找，找不到然后去服务器找)

3.反向代理负载均衡(用户通过反向代理服务器去找服务器)

4.IP 负载均衡

5.数据链路层负载均衡

---

负载均衡算法如下

• 轮询：所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场景。

• 加权轮询：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器分配更多请求。

• 随机：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用

加权随机算法。

• 最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。

• 源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，该算法可以保证同一个来源的请求总在同一个服务器上处理，实现会话粘滞。

---