架构师必备之高性能架构学习路线：消息中间件，Nginx，Redis等！

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了架构师必备之高性能架构学习路线：消息中间件，Nginx，Redis等！，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4949字，纯文字阅读大概需要8分钟。

内容图文

一）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等！全部内容，希望文章能够帮你解决架构师必备之高性能架构学习路线：消息中间件，Nginx，Redis等！所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---