主要功能:应用解耦,异步消息,流量削锋等问题架构设计:实现高性能,高可用,可伸缩和最终一致性架构常用消息队列:ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ使用场景:1)RabbitMQ:对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次(集群不能动态扩展)2)RocketMQ:具有高吞吐量、高可用性、适合大规模分布式系统应用的特点(支持的语言较少,语言支持的情况下优先选择)3)Kafka:基于Pull的模式来处理消息消费,追求高吞吐量,适合产生大量数据的互联网服务的数据收集业务(多数用于处理日志)
二、核心功能理解
解耦:一个事务,只关心核心的流程。而需要依赖其他系统但不那么重要的事情,有通知即可,无需等待结果异步消息:一致性:保证消息的可靠性1)强一致性:2)最终一致性:主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前,先把事情记录下来,然后去做不确定的事情,结果可能是:成功、失败或是不确定,“不确定”(例如超时等)可以等价为失败。成功就可以把记录的东西清理掉了,对于失败和不确定,可以依靠定时任务等方式把所有失败的事情重新执行一遍,直到成功为止
三、使用总结
2.对于一些无关痛痒,或者对于别人非常重要但是对于自己不是那么关心的事情,可以利用消息队列去做。
3.支持最终一致性的消息队列,能够用来处理延迟不那么敏感的“分布式事务”场景,而且相对于笨重的分布式事务,可能是更优的处理方式。
4.当上下游系统处理能力存在差距的时候,利用消息队列做一个通用的“漏斗”,在下游有能力处理的时候,再进行分发。
1)常用中间件:Varnish,Ngnix,Squid,Memcache,Redis,Ehcache等
1)过期策略:
(1)固定时间:比如指定缓存的时间是30分钟;
(2)相对时间:比如最近10分钟内没有访问的数据;
缓存的目的:将热点数据放到离用户最近或访问速度更快的介质中,加快数据的访问,减小响应时间
原理:CDN的基本原理是广泛采用各种缓存服务器,将缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求
CDN主要解决将数据缓存到离用户最近的位置,一般缓存静态资源文件(页面,脚本,图片,视频,文件等)。
国内网络异常复杂,跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题,可以在重要的城市,部署CDN应用。使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。
2)镜像服务:消除了不同运营商之间互联的瓶颈造成的影响,实现了跨运营商的网络加速,保证不同网络中的用户都能得到良好的访问质量
3)远程加速:远程访问用户根据DNS负载均衡技术智能自动选择Cache服务器,选择最快的Cache服务器,加快远程访问的速度
4)带宽优化:自动生成服务器的远程Mirror(镜像)cache服务器,远程用户访问时从cache服务器上读取数据,减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能
5)集群抗攻击:广泛分布的CDN节点加上节点之间的智能冗余机制,可以有效地预防黑客入侵以及降低各种
D.D.o.S攻击对网站的影响,同时保证较好的服务质量
1)动态资源缓存,需要注意实时性(解决方法:主要缓存静态资源,动态资源建立多级缓存或准实时同步)
2).如何保证数据的一致性和实时性需要权衡考虑(解决方法:设置缓存失效时间(1个小时,最终一致性))
目前,中小型互联网公司,综合成本考虑,一般租用第三方CDN服务,大型互联网公司,采用自建或第三方结合的方式。比如淘宝刚开始使用第三方的,当流量很大后,第三方公司无法支撑其CDN流量,淘宝最后采用自建CDN的方式实现。
原理:反向代理位于应用服务器机房,处理所有对WEB服务器的请求。如果用户请求的页面在代理服务器上有缓冲的话,代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求,取回数据,本地缓存后再发送给用户。通过降低向WEB服务器的请求数,从而降低了WEB服务器的负载代理缓存对比:常用的代理缓存有Varnish,Squid,Ngnix
2)Varnish采用内存型缓存,避免了频繁在内存、磁盘中交换文件,性能比Squid高;
3)Varnish由于是内存cache,所以对小文件如css,js,小图片啥的支持很棒,后端的持久化缓存可以采用的是Squid或ATS
4)Squid功能全而大,适合于各种静态的文件缓存,一般会在前端挂一个HAProxy或nginx做负载均衡跑多个实例
5)Nginx采用第三方模块ncache做的缓冲,性能基本达到varnish,一般作为反向代理使用,可以实现简单的缓存
Squid反向代理一般只缓存静态资源,动态程序默认不缓存。根据从WEB服务器返回的HTTP头标记来缓冲静态页面。有四个最重要HTTP头标记:
(3)否则这台Squid将没有缓存的请求根据配置的规则发送给邻居Squid和后台的WEB服务器处理;
CDN,反向代理缓存,主要解决静态文件,或用户请求资源的缓存,数据源一般为静态文件或动态生成的文件(有缓存头标识)。
分布式缓存,主要指缓存用户经常访问数据的缓存,数据源为数据库。一般起到热点数据访问和减轻数据库压力的作用。
目前分布式缓存设计,在大型网站架构中是必备的架构要素。常用的中间件有Memcache,Redis。
Memcache是一个高性能,分布式内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中,然后从内存中读取,从而大大提高读取速度。
特性:1)使用物理内存作为缓存区,可独立运行在服务器上。每个进程最大2G,如果想缓存更多的数据,可以开辟更多的memcache进程(不同端口)或者使用分布式memcache进行缓存,将数据缓存到不同的物理机或者虚拟机上
2)使用key-value的方式来存储数据,这是一种单索引的结构化数据组织形式,可使数据项查询时间复杂度为O
(1)
3)协议简单:基于文本行的协议,直接通过在memcached服务器上可进行存取数据操作,简单,方便
4)内置的内存管理方式:所有数据都保存在内存中,存取数据比硬盘快,当内存满后,通过LRU算法自动删除不使用的缓存,但没有考虑数据的容灾问题,重启服务,所有数据会丢失
5)分布式:各个memcached服务器之间互不通信,各自独立存取数据,不共享任何信息。服务器并不具有分布式功能,分布式部署取决于memcache客户端
6)缓存策略:Memcached的缓存策略是LRU(最近最少使用)到期失效策略。在memcached内存储数据项时,可以指定它在缓存的失效时间,默认为永久。当memcached服务器用完分配的内时,失效的数据被首先替换,然后也是最近未使用的数据。在LRU中,memcached使用的是一种LazyExpiration策略,自己不会监控存入的key/vlue对是否过期,而是在获取key值时查看记录的时间戳,检查key/value对空间是否过期,这样可减轻服务器的负载
1、MemCached介绍MemCached是一种基于内存的key-value存储,用来存储小块的任意数据(字符串、对象)。它便于快速开发,减轻开发难度,解决了大数据量缓存的很多问题,本质上,它是一个简洁的key-value存储系统
2、MemCached工作原理主要通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度。
工作流程1)先检查客户端的请求数据是否在memcached中,如有,直接把请求数据返回,不再对数据库进行任何操作
2)如果请求的数据不在memcached中,就去查数据库,把从数据库中获取的数据返回给客户端,同时把数据缓存一份到memcached中(memcached客户端不负责,需要程序实现)
4)当分配给memcached内存空间用完之后,会使用LRU(LeastRecentlyUsed,最近最少使用)策略加上到期失效策略,失效数据首先被替换,然后再替换掉最近未使用的数据
memcached虽然称为“分布式”缓存服务器,但服务器端并没有“分布式”功能。每个服务器都是完全独立和隔离的服务。memcached的分布式,是由客户端程序实现的。
当向memcached集群存入/取出keyvalue时,memcached客户端程序根据一定的算法计算存入哪台服务器,然后再把keyvalue值存到此服务器中。
(优点:计算简单,高效;缺点:在memcached服务器增加或减少时,几乎所有的缓存都会失效,危险:所有压力直接抵达后端,数据库会崩溃的)
2)散列算法:先算出memcached服务器的散列值,并将其分布到0到2的32次方的圆上,然后用同样的方法算出存储数据的键的散列值并映射至圆上,最后从数据映射到的位置开始顺时针查找,将数据保存到查找到的第一个服务器上,如果超过2的32次方,依然找不到服务器,就将数据保存到第一台memcached服务器上(添加了一台memcached服务器,只在圆上增加服务器的逆时针方向的第一台服务器上的键会受到影响)
一致性Hash算法:解决了余数算法增加节点命中大幅额度降低的问题,理论上,插入一个实体节点,平均会影响到:虚拟节点数/2的节点数据的命中。
简介:1)Redis是一个开源(BSD许可)的,基于内存的,多数据结构存储系统。可以用作数据库、缓存和消息中间件
2)支持多种类型的数据结构,如字符串(strings),散列(hashes),列表(lists),集合(sets),有序集合(sortedsets)与范围查询,bitmaps,hyperloglogs和地理空间(geospatial)索引半径查询
3)内置了复制(replication),LUA脚本(Luascripting),LRU驱动事件(LRUeviction),事务(transactions)和不同级别的磁盘持久化(persistence),并通过Redis哨兵(Sentinel)和自动分区(Cluster)提供高可用性(highavailability)
(1)缓存【失效】:客户端请求数据先从缓存中查询,如果没有再查询数据库,最后将数据放入缓存
(3)缓存【更新】:客户端写入数据到数据库,成功之后,让缓存失效(下次请求时从缓存中拿不到,则查询数据库,再放入缓存)
应用场景:String是最常用的一种数据类型,与Memcache的keyvalue存储方式类似。
实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。
RedisHash对应的Value,内部实际就是一个HashMap,实际这里会有2种不同实现。
(1)Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的valueredisObject的encoding为zipmap;
Redislist的应用场景非常多,也是Redis最重要的数据结构之
一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。
Redislist的实现为一个双向链表,可以支持反向查找和遍历,方便操作。不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。
Redisset对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。
set的内部实现是一个value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。
Redissortedset的使用场景与set类似,区别是set不是自动有序的,而sortedset可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,可以选择sortedset数据结构,比如twitter的publictimeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。
Redissortedset的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。
1.当Master挂了后,VIP漂移到Slave;Slave上keepalived通知redis执行:slaveofnoone,开始提供业务
2.当Master起来后,VIP地址不变,Master的keepalived通知redis执行slaveofslaveIPhost,开始作为从同步数据
1.关闭其中一台机器上所有redis,是得master全部切到另外一台机器(多实例部署,单机上既有主又有从的情况);并关闭机器
由twitter开源的c版本proxy,同时支持memcached和redis,目前最新版本为:0.2.4,持续开发中;/twitter/twemproxy.twitter用它主要减少前端与缓存服务间网络连接数。
特点:快、轻量级、减少后端CacheServer连接数、易配置、支持ketama、modula、random、常用hash分片算法。
3.高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备
2)当被监控的某个Redis节点出现问题时,哨兵(sentinel)可以通过API向管理员或者其他应用程序发送通知。
3)自动故障迁移(Automaticfailover):当一个Master不能正常工作时,哨兵(sentinel)会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master;当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效Master。
4)Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即,Master主服务器的redis.conf配置文件中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
6)缺点:Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题,运维人员在系统上线时必须确保有足够的空间,这对资源造成了很大的浪费;配置复杂
1)架构模式:支撑N个redismasternode,每个masternode都可以挂载多个slavenode(读写分离:写到master,然后读就从mater对应的slave去读)
2)使用场景:rediscluster,主要是针对海量数据 高并发 高可用的场景,海量数据,如果你的数据量很大,那么建议就用rediscluster
3)hashslot算法:(1)rediscluster有固定的个hashslot,对每个key计算CRC16值,然后对取模,可以获取key对应的hashslot(2)rediscluster中每个master都会持有部分slot,比如有3个master,那么可能每个master持有多个hashslot(3)hashslot让node的增加和移除很简单,增加一个master,就将其他master的hashslot移动部分过去,减少一个master,就将它的hashslot移动到其他master上去(移动hashslot的成本是非常低的)
(4)客户端的api,可以对指定的数据,让他们走同一个hashslot,通过hashtag来实现
(1)gossip:好处在于,元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,有一定的延时,降低了压力;缺点,元数据更新有延时,可能导致集群的一些操作会有一些滞后
(2)每个节点都有一个专门用于节点间通信的端口,就是自己提供服务的端口号 ,比如,那么用于节点间通信的就是端口(每个节点每隔一段时间都会往另外几个节点发送ping消息,同时其他几点接收到ping之后返回pong)
(1)meet:某个节点发送meet给新加入的节点,让新节点加入集群中,然后新节点就会开始与其他节点进行通信(2)ping:每个节点都会频繁给其他节点发送ping,其中包含自己的状态还有自己维护的集群元数据,互相通过ping交换元数据(3)pong:返回ping和meet,包含自己的状态和其他信息,也可以用于信息广播和更新(4)fail:某个节点判断另一个节点fail之后,就发送fail给其他节点,通知其他节点,指定的节点宕机了
6)高可用
(1)如果一个节点认为某个节点pfail了,那么会在gossipping消息中,ping给其他节点,如果超过半数的节点都认为pfail了,那么就会变成fail
(2)对宕机的masternode,从其所有的slavenode中,选择一个切换成masternode(检查每个slavenode与masternode断开连接的时间,如果超过了cluster-node-timeout*cluster-slave-validity-factor,那么就没有资格切换成master)
(3)每个从节点,都根据自己对master复制数据的offset,来设置一个选举时间,offset越大(复制数据越多)的从节点,选举时间越靠前,优先进行选举
(4)所有的masternode开始slave选举投票,给要进行选举的slave进行投票,如果大部分masternode(N/2 1)都投票给了某个从节点,那么选举通过,那个从节点可以切换成master
(5)从节点执行主备切换,从节点切换为主节点
数据结构:Memcache只支持keyvalue存储方式,Redis支持更多的数据类型,比如Keyvalue,hash,list,set,zset
多线程:Memcache支持多线程,redis支持单线程;CPU利用方面Memcache优于redis
过期策略:memcache过期后,不删除缓存,会导致下次取数据数据的问题,Redis有专门线程,清除缓存数据
(1)Redis和Memcache都是将数据存放在内存中,都是内存数据库。不过memcache还可用于缓存其他东西,例如图片、视频等等;
(2)Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,hash等数据结构的存储;
(3)虚拟内存–Redis当物理内存用完时,可以将一些很久没用到的value交换到磁盘;
a、memcache集群节点间的数据是独立的,不能相互通讯,但可以利用magent开源软件解决;
b、Redis高可用的,可以做一主多从,主从之间进行数据同步。当Master宕机后,通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务,
(5)存储数据安全–memcache挂掉后,数据没了;redis可以定期保存到磁盘(持久化);
(6)灾难恢复–memcache挂掉后,数据不可恢复;redis数据丢失后可以通过aof恢复;
Redis与其他key-value缓存产品有以下三个特点:
(1)Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
(2)Redis支持String、list、set、zset、hash等数据结构的存储。
硬盘缓存:将数据缓存到硬盘到,读取时从硬盘读取。原理是直接读取本机文件,减少了网络传输消耗,比通过网络读取数据库速度更快。可以应用在对速度要求不是很高,但需要大量缓存存储的场景
内存缓存:直接将数据存储到本机内存中,通过程序直接维护缓存对象,是访问速度最快的方式(适合少量缓存,对速度敏感的场景)
1)浏览器向客户端发起请求,如果CDN有缓存则直接返回2)如果CDN无缓存,则访问反向代理服务器;如果反向代理服务器有缓存则直接返回3)如果反向代理服务器无缓存或动态请求,则访问应用服务器4)应用服务器访问本地缓存;如果有缓存,则返回代理服务器,并缓存数据;(动态请求不缓存)5)如果本地缓存无数据,则读取分布式缓存;并返回应用服务器;应用服务器将数据缓存到本地缓存(部分)6)如果分布式缓存无数据,则应用程序读取数据库数据,并放入分布式缓存
从图中可以看出,两个并发写操作,由于某些原因(io阻塞,cpu时间片分配,协程调度,网络原因等等),导致Thread2的更新DB晚于Thread1的更新DB,但是Redis中此时的数据Thread1的,而DB中的数据时Thread2的,这就出现了不一致的问题,DB中是脏数据
从图中可以看出,两个并发写操作,由于某些原因导致Thread2的更新Redis晚于Thread1的更新Redis,但是DB中此时的数据Thread1的,而Redis中的数据时Thread2的,这就出现了不一致的问题
两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,会把老数据读出来后放到缓存中,然后更新操作更新了DB。于是,在缓存中的数据还是老的数据,导致缓存中的数据是脏的
(4)先数据库,成功之后,让缓存失效,下次请求时从缓存中拿不到,则查询数据库,再放入缓存。见下图:
这种更新策略是我们实际最常用的,但也可能出现问题。实际上出现问题的概率可能非常低,因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作。
而实际上数据库的写操作会比读操作慢得多,而且还要锁表,而读操作必需在写操作前进入数据库操作,而又要晚于写操作更新缓存,所有的这些条件都具备的概率基本并不大。
使用场景1)先写缓存,再写数据库:假如缓存写成功,但写数据库失败或响应延迟,则下次读取(并发读)缓存时,就出现脏读(不建议此种使用方式)
3)缓存异步刷新:需要考虑数据写入和缓存刷新的时效性(根据经验值确定合理的数据不一致时间,用户数据刷新的时间间隔)
指数据库操作和写缓存不在一个操作步骤中,比如在分布式场景下,无法做到同时写缓存或需要异步刷新(补救措施)时候。
(1)根据写入缓存的响应来进行判断,如果缓存写入失败,则回滚数据库操作;此种方法增加了程序的复杂度,不建议采用;
业界有两种理论,第一套缓存就是缓存,临时存储数据的,不需要高可用。第二种缓存逐步演化为重要的存储介质,需要做高可用。
缓存的高可用,一般通过分布式和复制实现。分布式实现数据的海量缓存,复制实现缓存数据节点的高可用。架构图如下:
(2)虚拟层:一致性Hash存在,假如其中一个HASH环不可用,数据会写入临近的环,当HASH可用时,数据又写入正常的HASH环,会导致数据偏移问题。这种情况,可以考虑在HASH环前面加一个虚拟层实现。
(3)多级缓存:比如一级使用本地缓存,二级采用分布式Cahce,三级采用分布式Cache 本地持久化;
十、缓存雪崩:雪崩是指当大量缓存失效时,导致大量的请求访问数据库,导致数据库服务器,无法抗住请求或挂掉的情况
合理规划缓存的失效时间;合理评估数据库的负载压力;对数据库进行过载保护或应用层限流多级缓存设计,缓存高可用
现象:缓存一般是Key,value方式存在,当某一个Key不存在时会查询数据库,假如这个Key,一直不存在,则会频繁的请求数据库,对数据库造成访问压力
2)一定不存在的key,采用布隆过滤器,建立一个大的Bitmap中,查询时通过该bitmap过滤