Week 5 作业 02
各种缓存
CPU 缓存 ，操作系统缓存， 数据库缓存 ， JVM 编译缓存 ，CDN 缓存 ，代理与反向代理缓存 ，前端缓存 ，应用程序缓存 ，分布式对象缓存。
缓存的关键指标，就是命中率，如果呼叫资源10次有9 次从缓存返回呼叫方，那么命中率为90%。
影响缓存命中率的主要指标
缓存键集合大小 （hash key）
缓存中的每个对象使用缓存键进行 识别，定位一个对象的唯一方式就是对缓存键执行精 确匹配。例如，如果想为每个商品缓 存在线商品信息，你需要使用商品 ID 作为缓存键。 换句话说，缓存键空间是你的应用能 够生成的所有键的数量。从统计数字上看，应用生 成的唯一键越多，重用的机会越小。例 如，如果想基于客户 IP 地址缓存天气数据，则 可能有多达 40 亿个键(这是所有可能的 IP 地址的数量)。如果要基于客户来源国家缓存 天气数据，则可能仅需几百个缓存键(世界上所有国家的数量)。一定要想办法减少可能的 缓存键数量。键数量越少，缓存的效率越高。
缓存可使用内存空间 （RAM）
缓存可使用内存空间直接决定了缓存对象的平均大小和缓存对象数量。因为缓存通常存 储在内存中，缓存对象可用空间受到严格限制且 相对昂贵。如果想缓存更多的对象，就 需要先删除老的对象，再添加新的对象。替换(清除)对象会降低缓存命中率，因为缓存对 象被删除后，将来的请求就无法命中了。物理上能缓存的对象越多，缓存命中率就越高。
缓存对象生存时间（Expired）
缓存对象生存时间称为 TTL（ Time To Live ）。在某些场景中，例如，缓存天气预报数 据 15 分钟没问题。在这个场景下， 你可以设置缓存对象预定义 TTL 为 15 分钟。在其 他场景中，你可能不能冒险使用过于陈旧的数据。例如，在一个电子商务系统中，店铺 管理员可能在任何时刻修改商品价格，如果这些价格需要准确地展示在整个网站中。在 这个场景下，你需要在每次商品价格修改时让缓存失效。简单讲，对象缓存的时间越长， 缓存对象被重用的可能性就越高。
代理缓存
多为公司内部设置，为了节省对外网络频宽。
反向代理缓存
多为小型web服务公司设置
除了减少web 服务器压力，也可以通过反向代理缓存解决用户网络连线问题
CDN 缓存
多数互联网公司使用
可以理解为反向代理的集合
通读缓存（read-through）
代理缓存，反向代理缓存，CDN 缓存都是通读缓存。
通读缓存给客户端返回缓存资源，并在请求未命中缓存时获取实际数据。
客户端连接的是通读缓存而不是生成响应的原始服务器
旁路缓存（cache-aside）
对象缓存是一种旁路缓存，旁路缓存通常是一个独立的键值对（key-value）存储。
应用代码通常会询问对象缓存需要的对象是否存在，如果存在，它会获取并使用缓存 的对象，如果不存在或已过期， 应用会连接主数据源来组装对象，并将其保存回对象 缓存中以便将来使用。
使用这个的时候，要对数据库不存在的data做处理。例如：在缓存处对不存在的data做统一返回。避免被CC 攻击。
浏览器对象缓存
// 在WebStorage中缓存对象的JavaScript代码
// 访问缓存对象的JavaScript代码
本地对象缓存
对象直接缓存在应用程序内存中 。
对象存储在共享内存，同一台机器的多个进程可以访问它们。
缓存服务器作为独立应用和应用程序部署在同一个服务器上。
一致性 Hash
https://xie.infoq.cn/article/a64c2d559b2195e37753ca79e
各种介质数据访问延迟
技术栈各个层次的缓存
缓存为什么能显著提升性能
缓存数据通常来自内存，比磁盘上的数据有更快的访问速度。
缓存存储数据的最终结果形态，不需要中间计算，减少 CPU 资源的消耗。
缓存降低数据库、磁盘、网络的负载压力，使这些 I/O 设备获得更好的响应特性。
缓存是系统性能优化的大杀器
技术简单
性能提升显著
应用场景多
合理使用缓存
使用缓存对提高系统性能有很多好处，但是不合理的使用缓存可能非但不能提高系统的 性能，还会成为系统的累赘，甚至风险。实践中，缓存滥用的情景屡见不鲜——过分依 赖缓存、不合适的数据访问特性等。
频繁修改的数据 - 这种数据如果缓存起来，由于频繁修改，应用还来不及读取就已失效 或更新，徒增系统负担。一般说来，数据的读写比在2:1以上，缓存才有意义。
没有热点的访问：缓存使用内存作为存储，内存资源宝贵而有限，不能将所有数据都缓 存起来，如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问不是集 中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被 挤出缓存了。
数据不一致与脏读：一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数 据库中重新加载。因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性， 但是需要过一段时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的， 但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存，不过也会带来 更多系统开销和事务一致性的问题。因此数据更新时通知缓存失效，删除该缓存数据， 是一种更加稳妥的做法。
“计算机科学中只有三件事最困难:缓存失效，命名事物，计数错误。” ——Phil Karlton
缓存雪崩：缓存是为了提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到 应用程序的处——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大 部分的数据访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃的时候， 数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况， 被称作缓存雪崩，发生这种故障，甚至不能简单的重启缓存服务器和数据库服务器来恢 复网站访问。
缓存预热：缓存中存放的是热点数据，热点数据又是缓存系统利用 LRU（最近最久未用） 算法对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间，在这段时间， 系统的性能和数据库负载都不太好，那么最好在缓存系统启动的时候就把热点数据加载 好，这个缓存预加载手段叫做缓存预热（warm up）。对于一些元数据如城市地名列表、 类目信息，可以启动时加载数据库中全部数据到缓存进行预热。
缓存穿透：如果不恰当的业务、或者恶意攻击持续高并发的请求某个不存在的数据，因 为缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大的压力， 甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其 value 值为 null），并设 定一个较短的失效时间。
Redis VS Memcached
Redis 支持复杂的数据结构
Redis 支持多路复用异步 I/O 高性能
Redis 支持主从复制高可用
Redis 原生集群与 share nothing 集群模式
Redis 集群
Redis 集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个 key放到哪个桶中。
redis-cluster 把所有的物理节点映射到[0- 16383]slot上（不一定是平均分配）， cluster 负责维护 slot 与服务器的映射关系。
客户端与 Redis 节点直连，客户端不需要连 接集群所有节点，连接集群中任何一个可用 节点即可。
所有的 Redis 节点彼此互联。
消息队列与异步架构
消息队列构建异步调用架构
点对点模型
发布订阅模型
消息队列好处
实现异步处理，提升处理性能
更好的伸缩性
削峰填谷
失败隔离和自我修复
因为发布者不直接依赖消费者，所以消息系统可以将消费者系统错误与生产者系统组件 隔离。 生产者和消费者互相不受对方失败影响。 这意味着任意时刻，我们都可以对后端服务器执行维护和发布操作。我们可以重启、添 加或删除服务 器而不影响生产者可用性，这样简化了部署和服务器管理的难度。
解耦
事件驱动架构 EDA
主要 MQ 产品比较
RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟 悉 Erlang 的同学而言不便于二次开发和维护。（49M）
ActiveMQ 影响比较广泛，可以跨平台，使用Java开发，对Java比较友好。（27M）
RocketMQ 是阿里推出的一个开源产品，也是使用Java开发，性能比较好，可靠性也 比较高。（35M）
Kafka ，LinkedIn 出品的，Scala 开发，专门针对分布式场景进行了优化，因此分布 式的伸缩性会比较好。（63M）
负载均衡架构
HTTP 重定向负载均衡
DNS 负载均衡
反向代理负载均衡
IP 负载均衡
数据链路层负载均衡
负载均衡算法
轮询：所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场 景。
加权轮询：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请 求分发到每个服务器，高性能的服务器分配更多请求。
随机：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用， 因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用 加权随机算法。
最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到 最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。
源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，该算法可以保 证同一个来源的请求总在同一个服务器上处理，实现会话粘滞。
应用服务器集群的 Session 管理
应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有 状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买 请求都是向购物车中增加商品；在社交类的网站中，需要记录用户的当前登录状态、最 新发布的消息等以便及时将这些信息通知给他的好友。Web 应用中将这些状态信息称作 会话（Session），单机情况下，Session 可交给 Web 容器管理，在使用负载均衡的集 群环境中，Session 管理主要有以下几种手段。
Session 复制
Session 绑定
利用 Cookie 记录 Session
Session 服务器
分布式数据库
MySQL 主从复制
MySQL 一主多从复制
一主多从复制的优点
分摊负载
专机专用
便于冷备
高可用
MySQL 主主复制
MySQL 主主失效恢复
MySQL 主主失效的维护过程
MySQL 复制注意事项：
主主复制的两个数据库不能并发写入。
复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力。
更新表结构会导致巨大的同步延迟。
数据分片 （partition）
分片目标
分片特点
分片原理
硬编码实现数据分片
映射表外部存储
数据分片的挑战
需要大量的额外代码，处理逻辑因此变得更加复杂。
无法执行多分片的联合查询。
无法使用数据库的事务。
随着数据的增长，如何增加更多的服务器。
分布式数据库中间件
分布式数据库中间件TDDL、Amoeba、Cobar、MyCAT架构比较
比较了业界流行的MySQL分布式数据库中间件，关于每个产品的介绍，网上的资料比较多，本文只是对几款产品的架构进行比较，从中可以看出中间件发展和演进路线
框架比较
TDDL
Amoeba
Cobar
MyCat
点评
TDDL不同于其它几款产品，并非独立的中间件，只能算作中间层，是以Jar包方式提供给应用调用。属于JDBC Shard的思想，网上也有很多其它类似产品。
另外，网上有关于TDDL的图，如http://www.tuicool.com/articles/nmeuu2中的图 1-2 TDDL 所处领域模型定位，把TDDL画在JDBC下层了，这个是不对的，正确的位置是TDDL夹在业务层和JDBC中间
Amoeba是作为一个真正的独立中间件提供服务，即应用去连接Amoeba操作MySQL集群，就像操作单个MySQL一样。从架构中可以看来，Amoeba算中间件中的早期产品，后端还在使用JDBC Driver。
Cobar是在Amoeba基础上进化的版本，一个显著变化是把后端JDBC Driver改为原生的MySQL通信协议层。
后端去掉JDBC Driver后，意味着不再支持JDBC规范，不能支持Oracle、PostgreSQL等数据。但使用原生通信协议代替JDBC Driver，后端的功能增加了很多想象力，比如主备切换、读写分离、异步操作等。
MyCat又是在Cobar基础上发展的版本，两个显著点是：
后端由BIO改为NIO，并发量有大幅提高
增加了对Order By、Group By、limit等聚合功能的支持（，虽然Cobar也可以支持Order By、Group By、limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）。
目前社区情况：
TDDL处于停滞状态
Amoeba处于停滞状态
Cobar处于停滞状态
MyCAT社区非常活跃
感想：抛开TDDL不说，Amoeba、Cobar、MyCAT这三者的渊源比较深，若Amoeba能继续下去，Cobar就不会出来；若Cobar那批人不是都走光了的话，MyCAT也不会再另起炉灶。所以说，在中国开源的项目很多，但是能坚持下去的非常难，MyCAT社区现在非常活跃，也真是一件蛮难得的事。
其它资料
这个博客把几款产品的资料汇总在一起，倒也省得大家在网上到处搜了。
mysql中间件研究(Atlas，cobar，TDDL，mycat，heisenberg,Oceanus,vitess)
http://songwie.com/articlelist/44
mysql中间件研究（Atlas，cobar，TDDL）
http://www.guokr.com/blog/475765/
作者：保罗大哥
链接：https://www.jianshu.com/p/ed54162d720c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。比较了业界流行的MySQL分布式数据库中间件，关于每个产品的介绍，网上的资料比较多，本文只是对几款产品的架构进行比较，从中可以看出中间件发展和演进路线
框架比较
TDDL
Amoeba
Cobar
MyCat
点评
TDDL不同于其它几款产品，并非独立的中间件，只能算作中间层，是以Jar包方式提供给应用调用。属于JDBC Shard的思想，网上也有很多其它类似产品。
另外，网上有关于TDDL的图，如http://www.tuicool.com/articles/nmeuu2中的图 1-2 TDDL 所处领域模型定位，把TDDL画在JDBC下层了，这个是不对的，正确的位置是TDDL夹在业务层和JDBC中间
Amoeba是作为一个真正的独立中间件提供服务，即应用去连接Amoeba操作MySQL集群，就像操作单个MySQL一样。从架构中可以看来，Amoeba算中间件中的早期产品，后端还在使用JDBC Driver。
Cobar是在Amoeba基础上进化的版本，一个显著变化是把后端JDBC Driver改为原生的MySQL通信协议层。
后端去掉JDBC Driver后，意味着不再支持JDBC规范，不能支持Oracle、PostgreSQL等数据。但使用原生通信协议代替JDBC Driver，后端的功能增加了很多想象力，比如主备切换、读写分离、异步操作等。
MyCat又是在Cobar基础上发展的版本，两个显著点是：
后端由BIO改为NIO，并发量有大幅提高
增加了对Order By、Group By、limit等聚合功能的支持（，虽然Cobar也可以支持Order By、Group By、limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）。
目前社区情况：
TDDL处于停滞状态
Amoeba处于停滞状态
Cobar处于停滞状态
MyCAT社区非常活跃
感想：抛开TDDL不说，Amoeba、Cobar、MyCAT这三者的渊源比较深，若Amoeba能继续下去，Cobar就不会出来；若Cobar那批人不是都走光了的话，MyCAT也不会再另起炉灶。所以说，在中国开源的项目很多，但是能坚持下去的非常难，MyCAT社区现在非常活跃，也真是一件蛮难得的事。
其它资料
这个博客把几款产品的资料汇总在一起，倒也省得大家在网上到处搜了。
mysql中间件研究(Atlas，cobar，TDDL，mycat，heisenberg,Oceanus,vitess)
http://songwie.com/articlelist/44
mysql中间件研究（Atlas，cobar，TDDL）
http://www.guokr.com/blog/475765/
作者：保罗大哥
链接：https://www.jianshu.com/p/ed54162d720c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。比较了业界流行的MySQL分布式数据库中间件，关于每个产品的介绍，网上的资料比较多，本文只是对几款产品的架构进行比较，从中可以看出中间件发展和演进路线
框架比较
TDDL
Amoeba
Cobar
MyCat
点评
TDDL不同于其它几款产品，并非独立的中间件，只能算作中间层，是以Jar包方式提供给应用调用。属于JDBC Shard的思想，网上也有很多其它类似产品。
另外，网上有关于TDDL的图，如http://www.tuicool.com/articles/nmeuu2中的图 1-2 TDDL 所处领域模型定位，把TDDL画在JDBC下层了，这个是不对的，正确的位置是TDDL夹在业务层和JDBC中间
Amoeba是作为一个真正的独立中间件提供服务，即应用去连接Amoeba操作MySQL集群，就像操作单个MySQL一样。从架构中可以看来，Amoeba算中间件中的早期产品，后端还在使用JDBC Driver。
Cobar是在Amoeba基础上进化的版本，一个显著变化是把后端JDBC Driver改为原生的MySQL通信协议层。
后端去掉JDBC Driver后，意味着不再支持JDBC规范，不能支持Oracle、PostgreSQL等数据。但使用原生通信协议代替JDBC Driver，后端的功能增加了很多想象力，比如主备切换、读写分离、异步操作等。
MyCat又是在Cobar基础上发展的版本，两个显著点是：
后端由BIO改为NIO，并发量有大幅提高
增加了对Order By、Group By、limit等聚合功能的支持（，虽然Cobar也可以支持Order By、Group By、limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）。
目前社区情况：
TDDL处于停滞状态
Amoeba处于停滞状态
Cobar处于停滞状态
MyCAT社区非常活跃
感想：抛开TDDL不说，Amoeba、Cobar、MyCAT这三者的渊源比较深，若Amoeba能继续下去，Cobar就不会出来；若Cobar那批人不是都走光了的话，MyCAT也不会再另起炉灶。所以说，在中国开源的项目很多，但是能坚持下去的非常难，MyCAT社区现在非常活跃，也真是一件蛮难得的事。
其它资料
这个博客把几款产品的资料汇总在一起，倒也省得大家在网上到处搜了。
mysql中间件研究(Atlas，cobar，TDDL，mycat，heisenberg,Oceanus,vitess)
http://songwie.com/articlelist/44
mysql中间件研究（Atlas，cobar，TDDL）
http://www.guokr.com/blog/475765/
作者：保罗大哥
链接：https://www.jianshu.com/p/ed54162d720c
来源：简书
数据库部署方案 - 单一服务与单一数据库
数据库部署方案 – 主从复制实现伸缩
数据库部署方案 -两个 Web 服务及两个数据库
数据库部署方案 – 综合部署
NoSQL
一致性Consistency: 一致性是说，每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据，也就是说，数据是一致 的。
可用性Availability: 可用性是说，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过 这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系 统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是 最新的。
分区耐受性Partition tolerance: 分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依 然应该是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。
CAP 原理
当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不 可用；要么我们继续写入数据，但是数据的一致性就得不到保证。 对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证 的，那么在可用性和一致性上就必须二选一。 当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个 错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个 数据，但是并不能保证这个数据是最新的。 所以，关于 CAP 原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下， 可用性和一致性无法同时满足。
CAP 原理与数据一致性冲突
最终一致性
最终一致写冲突
简单冲突处理策略：根据时间戳，最后写入覆盖。
客户端冲突解决
投票解决冲突（Cassandra ）
Cassandra 分布式架构
Hbase 架构
Log Structed Merge Tree（LSM 树）
ACID
原子性（Atomicity）: 事务要么全部完成，要么全部取消。 如果事务崩溃，状态回到 事务之前（事务回滚）。
隔离性（Isolation）: 如果2个事务 T1 和 T2 同时运行，事务 T1 和 T2 最终的结果是 相同的，不管 T1和T2谁先结束，隔离性主要依靠锁实现。
持久性（Durability）: 一旦事务提交，不管发生什么（崩溃或者出错），数据要保存 在数据库中。
一致性（Consistency）: 只有合法的数据（依照关系约束和函数约束）才能写入数据 库。
BASE
基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如 响应时间上的损失或功能上的损失。
Soft state（弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的 存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步 的过程存在延时。
Eventually consistent（最终一致性）指系统中所有的数据副本，在经过一段时间的同步 后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达 到一致，而不需要实时保证系统数据的强一致性。
还未添加个人签名 2019.01.05 加入
还未添加个人简介
评论