架构师必备之高性能架构学习路线:消息中间件,Nginx,Redis等!
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构师必备之高性能架构学习路线:消息中间件,Nginx,Redis等!相关的知识,希望对你有一定的参考价值。
一)Zookeeper分布式环境指挥官zookeeper基础
ZooKeeper是一种分布式协调服务,用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑,而不必担心应用程序的分布式特性。
分布式应用的优点
(1)可靠性?- 单个或几个系统的故障不会使整个系统出现故障。
(2)可扩展性?- 可以在需要时增加性能,通过添加更多机器,在应用程序配置中进行微小的更改,而不会有停机时间。
(3)透明性?- 隐藏系统的复杂性,并将其显示为单个实体/应用程序。
分布式应用的挑战
(1)竞争条件?- 两个或多个机器尝试执行特定任务,实际上只需在任意给定时间由单个机器完成。例如,共享资源只能在任意给定时间由单个机器修改。
(2)死锁?- 两个或多个操作等待彼此无限期完成。
(3)不一致?- 数据的部分失败。
二)Nginx高并发分流进阶实战
nginx如何实现高并发
简单来讲,就是异步,非阻塞,使用了epoll和大量的底层代码优化。
稍微详细一点展开的话,就是nginx的特殊进程模型和事件模型的设计。
进程模型
nginx采用一个master进程,多个woker进程的模式。
master进程主要负责收集、分发请求。当一个请求过来时,master拉起一个worker进程负责处理这个请求。
master进程也要负责监控woker的状态,保证高可靠性
woker进程一般设置为跟cpu核心数一致。nginx的woker进程跟apache不一样。apche的进程在同一时间只能处理一个请求,所以它会开很多个进程,几百甚至几千个。而nginx的woker进程在同一时间可以处理额请求数只受内存限制,因此可以处理多个请求。
事件模型
nginx是异步非阻塞的。
每进来一个request,会有一个worker进程去处理。但不是全程的处理,处理到什么程度呢?处理到可能发生阻塞的地方,比如向上游(后端)服务器转发request,并等待请求返回。那么,这个处理的worker不会这么傻等着,他会在发送完请求后,注册一个事件:“如果upstream返回了,告诉我一声,我再接着干”。于是他就休息去了。此时,如果再有request 进来,他就可以很快再按这种方式处理。而一旦上游服务器返回了,就会触发这个事件,worker才会来接手,这个request才会接着往下走。
web server的工作性质决定了每个request的大部份生命都是在网络传输中,实际上花费在server机器上的时间片不多。这是几个进程就解决高并发的秘密所在。
三)rabbitMQ消息中间件
(1)Broker: 消息中间件实例, 可能是单个节点也可能是运行在多节点集群上的逻辑实体
(2)消息(Message):消息由消息头和消息体两部分组成。消息头中包括routing-key、priority等标准消息头以及其它自定义消息头,用于定义RabbitMQ对消息行为。消息体是字节流,包含消息内容。
(3)连接(Connection):客户端与 Broker 之间的 TCP连接
(4)信道(Channel)?Channel 是建立在 TCP 连接上的逻辑(虚拟)连接。多个 Channel 复用同一个 TCP 连接, 以避免建立 TCP 连接的巨大开销。 RabbitMQ 官方要求每个线程使用独立的 Channel, 禁止多个线程共用 Channel。
(5)生产者(Publisher):发送消息的客户端线程
(6)消费者(Consumer):处理消息的客户端线程
(7)交换机(Exchange):交换机负责将消息投递到相应的队列
(8)队列(Queue):?接收并保存交换机投递的消息,直至被消费者成功消费。逻辑结构遵循先进先出FIFO。
(9)绑定(Binding):?将队列(Queue)注册到交换机(Exchange)的路由表
(10)虚拟主机(Vhost):?每个Broker下可建立多个vhost, 每个 vhost 可建立独立的 Exchange、Queue、绑定及权限系统。同一个 Broker 下的 vhost 共享 Connection、Channel 和 用户系统,就是说可以使用同一个用户身份使用同一个 Channel 访问不同 vhost。
四)ActiveMQ消息中间件
(1)多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,php。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
(2)完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
(3) 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性
(4) 通过了常见J2EE服务器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试,其中通过JCA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
(5) 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
(6)支持通过JDBC和journal提供高速的消息持久化
(7)从设计上保证了高性能的集群,客户端-服务器,点对点
(8) 支持Ajax
(9)支持与Axis的整合
(10)可以很容易的调用内嵌JMS provider,进行测试
五)Redis高性能缓存数据库
Redis的数据结构和相关常用命令
Key:Redis采用Key-Value型的基本数据结构,任何二进制序列都可以作为Redis的Key使用(例如普通的字符串或一张JPEG图片)
String:String是Redis的基础数据类型,Redis没有Int、Float、Boolean等数据类型的概念,所有的基本类型在Redis中都以String体现。
SET:为一个key设置value,可以配合EX/PX参数指定key的有效期,通过NX/XX参数针对key是否存在的情况进行区别操作,时间复杂度O(1)
GET:获取某个key对应的value,时间复杂度O(1)
GETSET:为一个key设置value,并返回该key的原value,时间复杂度O(1)
MSET:为多个key设置value,时间复杂度O(N)
MSETNX:同MSET,如果指定的key中有任意一个已存在,则不进行任何操作,时间复杂度O(N)
MGET:获取多个key对应的value,时间复杂度O(N)
INCR:将key对应的value值自增1,并返回自增后的值。只对可以转换为整型的String数据起作用。时间复杂度O(1)
INCRBY:将key对应的value值自增指定的整型数值,并返回自增后的值。只对可以转换为整型的String数据起作用。时间复杂度O(1)
DECR/DECRBY:同INCR/INCRBY,自增改为自减。
六)项目实战资料
(1)kafka百万级吞实战
(2)Memcached进阶实战
(3)高性能缓存开发实战
(4)MongoDB进阶实战
需要项目资料可以关注我的公众号:【风平浪静如码】点资料领取即可获取!
觉得写的还不错的就点个赞,加个关注呗!点关注,不迷路,持续更新!!!
以上是关于架构师必备之高性能架构学习路线:消息中间件,Nginx,Redis等!的主要内容,如果未能解决你的问题,请参考以下文章