【笔记与博客收集】服务端相关知识点

1. 服务端技术介绍&＃xff08;系统架构纬度&＃xff09;&＃xff1a;
   &＃xff08;1&＃xff09; 服务端开发的技术栈
   

&＃xff08;2&＃xff09; 基础设施&＃xff1a;

• 操作系统
• 网络设施
• 机房机架

&＃xff08;3&＃xff09;支撑系统&＃xff1a;

• 日志系统
• 监控报警
• 运维系统

&＃xff08;4&＃xff09; 接入层&＃xff1a;

• 反向代理请求
• Nginx
• 负载均衡
• 轮询/随机/权重
• hash/一致性 hash
  

&＃xff08;5&＃xff09; 逻辑层&＃xff1a;

• 根据业务逻辑&＃xff0c;处理用户请求&＃xff0c;得到返回结果
• 单体式服务&＃xff1a;所有业务逻辑集中在一个代码仓库&＃xff0c;一个进程里
• 简单&＃xff0c;适合协作人数少&＃xff0c;功能少
• 维护/更新方便
• 难以支持高复杂度系统
• 微服务
• 多人团队协作成本更低
• 功能复用、系统解耦、故障隔离
• 影响性能&＃xff0c;系统复杂度指数性上升&＃xff0c;对业务设计流程要求更高
  

&＃xff08;6&＃xff09; 存储层&＃xff1a;

• 数据的 存储/转发/查询
• SQL类关系型存储
• NoSQL类Key-Value存储
• 分布式文件系统
• 队列存储

2. 网络协议&＃xff1a;HTTP/ HTTPS &＃xff08;以下内容来自HTTP与HTTPS的区别&＃xff09;
   &＃xff08;1&＃xff09; HTTP和HTTPS的基本概念
   HTTP&＃xff08;HyperText Transfer Protocol&＃xff1a;超文本传输协议&＃xff09;是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法&＃xff0c;被用于在 Web 浏览器和网站服务器之间传递信息。
   HTTP 默认工作在 TCP 协议 80 端口&＃xff0c;用户访问网站 http:// 打头的都是标准 HTTP 服务。
   HTTP 协议以明文方式发送内容&＃xff0c;不提供任何方式的数据加密&＃xff0c;如果攻击者截取了Web浏览器和网站服务器之间的传输报文&＃xff0c;就可以直接读懂其中的信息&＃xff0c;因此&＃xff0c;HTTP协议不适合传输一些敏感信息&＃xff0c;比如&＃xff1a;信用卡号、密码等支付信息。
   HTTPS&＃xff08;Hypertext Transfer Protocol Secure&＃xff1a;超文本传输安全协议&＃xff09;是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信&＃xff0c;但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的&＃xff0c;是提供对网站服务器的身份认证&＃xff0c;保护交换数据的隐私与完整性。
   HTTPS 默认工作在 TCP 协议443端口&＃xff0c;它的工作流程一般如以下方式&＃xff1a;

   1. TCP 三次同步握手
   2. 客户端验证服务器数字证书
   3. DH 算法协商对称加密算法的密钥、hash 算法的密钥
   4. SSL 安全加密隧道协商完成
   5. 网页以加密的方式传输&＃xff0c;用协商的对称加密算法和密钥加密&＃xff0c;保证数据机密性&＃xff1b;用协商的hash算法进行数据完整性保护&＃xff0c;保证数据不被篡改。

   &＃xff08;2&＃xff09; HTTP 与 HTTPS 区别

   • HTTP 明文传输&＃xff0c;数据都是未加密的&＃xff0c;安全性较差&＃xff0c;HTTPS&＃xff08;SSL&＃43;HTTP&＃xff09; 数据传输过程是加密的&＃xff0c;安全性较好。
   • 使用 HTTPS 协议需要到 CA&＃xff08;Certificate Authority&＃xff0c;数字证书认证机构&＃xff09; 申请证书&＃xff0c;一般免费证书较少&＃xff0c;因而需要一定费用。证书颁发机构如&＃xff1a;Symantec、Comodo、GoDaddy 和 GlobalSign 等。
   • HTTP 页面响应速度比 HTTPS 快&＃xff0c;主要是因为 HTTP 使用 TCP 三次握手建立连接&＃xff0c;客户端和服务器需要交换 3 个包&＃xff0c;而 HTTPS除了 TCP 的三个包&＃xff0c;还要加上 ssl 握手需要的 9 个包&＃xff0c;所以一共是 12 个包。
   • http 和 https 使用的是完全不同的连接方式&＃xff0c;用的端口也不一样&＃xff0c;前者是 80&＃xff0c;后者是 443。
   • HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议&＃xff0c;所以&＃xff0c;要比较 HTTPS 比 HTTP 要更耗费服务器资源。

   &＃xff08;3&＃xff09; HTTPS的工作原理
   

   • 客户端发起 HTTPS 请求
     这个没什么好说的&＃xff0c;就是用户在浏览器里输入一个 https 网址&＃xff0c;然后连接到 server 的 443 端口。

   • 服务端的配置
     采用 HTTPS 协议的服务器必须要有一套数字证书&＃xff0c;可以自己制作&＃xff0c;也可以向组织申请&＃xff0c;区别就是自己颁发的证书需要客户端验证通过&＃xff0c;才可以继续访问&＃xff0c;而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择&＃xff0c;有 1 年的免费服务)。
     这套证书其实就是一对公钥和私钥&＃xff0c;如果对公钥和私钥不太理解&＃xff0c;可以想象成一把钥匙和一个锁头&＃xff0c;只是全世界只有你一个人有这把钥匙&＃xff0c;你可以把锁头给别人&＃xff0c;别人可以用这个锁把重要的东西锁起来&＃xff0c;然后发给你&＃xff0c;因为只有你一个人有这把钥匙&＃xff0c;所以只有你才能看到被这把锁锁起来的东西。

   • 这个证书其实就是公钥&＃xff0c;只是包含了很多信息&＃xff0c;如证书的颁发机构&＃xff0c;过期时间等等。

   • 客户端解析证书
     部分工作是有客户端的TLS来完成的&＃xff0c;首先会验证公钥是否有效&＃xff0c;比如颁发机构&＃xff0c;过期时间等等&＃xff0c;如果发现异常&＃xff0c;则会弹出一个警告框&＃xff0c;提示证书存在问题。
     如果证书没有问题&＃xff0c;那么就生成一个随机值&＃xff0c;然后用证书对该随机值进行加密&＃xff0c;就好像上面说的&＃xff0c;把随机值用锁头锁起来&＃xff0c;这样除非有钥匙&＃xff0c;不然看不到被锁住的内容。

   • 传送加密信息
     这部分传送的是用证书加密后的随机值&＃xff0c;目的就是让服务端得到这个随机值&＃xff0c;以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

   • 服务段解密信息
     服务端用私钥解密后&＃xff0c;得到了客户端传过来的随机值(私钥)&＃xff0c;然后把内容通过该值进行对称加密&＃xff0c;所谓对称加密就是&＃xff0c;将信息和私钥通过某种算法混合在一起&＃xff0c;这样除非知道私钥&＃xff0c;不然无法获取内容&＃xff0c;而正好客户端和服务端都知道这个私钥&＃xff0c;所以只要加密算法够彪悍&＃xff0c;私钥够复杂&＃xff0c;数据就够安全。

   • 传输加密后的信息
     这部分信息是服务段用私钥加密后的信息&＃xff0c;可以在客户端被还原。

   • 客户端解密信息
     客户端用之前生成的私钥解密服务段传过来的信息&＃xff0c;于是获取了解密后的内容&＃xff0c;整个过程第三方即使监听到了数据&＃xff0c;也束手无策。

3. 数据的封装和交换&＃xff1a;JSON/ XML/ Protocol buffers
   &＃xff08;1&＃xff09; JSON
   JSON (Javascript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于Javascript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。JSON采用完全独立于语言的文本格式&＃xff0c;但是也使用了类似于C语言家族的习惯&＃xff08;包括C, C&＃43;&＃43;, C#, Java, Javascript, Perl, Python等&＃xff09;。这些特性使JSON成为理想的数据交换语言。
   JSON建构于两种结构&＃xff1a;
   o “名称/值”对的集合&＃xff08;A collection of name/value pairs&＃xff09;。不同的语言中&＃xff0c;它被理解为对象&＃xff08;object&＃xff09;&＃xff0c;纪录&＃xff08;record&＃xff09;&＃xff0c;结构&＃xff08;struct&＃xff09;&＃xff0c;字典&＃xff08;dictionary&＃xff09;&＃xff0c;哈希表&＃xff08;hash table&＃xff09;&＃xff0c;有键列表&＃xff08;keyed list&＃xff09;&＃xff0c;或者关联数组&＃xff08;associative array&＃xff09;。
   o 值的有序列表&＃xff08;An ordered list of values&＃xff09;。在大部分语言中&＃xff0c;它被理解为数组&＃xff08;array&＃xff09;。
   其中&＃xff0c;值的基础类型一般为字符串&＃xff08;String&＃xff09;&＃xff0c;数值&＃xff08;Number&＃xff09;&＃xff0c;布尔值&＃xff08;Boolean&＃xff09;等。

   JSON规则相对简单&＃xff1a;

   • 单一映射用”:”分隔&＃xff0c;即”名称/值”对
   • 并列的映射/数据用”,”分隔
   • 有序列表用”[]”表示
   • 映射集合用”{}”表示

   理论上&＃xff0c;所有的数据结构均可以使用该规则进行定义。

   实例&＃xff1a;
   
   &＃xff08;2&＃xff09; XML
   XML&＃xff1a;可扩展标记语言&＃xff08;eXtensible Markup Language&＃xff09;&＃xff0c;被设计用来传输和存储数据。在大多数Web应用程序中&＃xff0c;XML用于传输数据&＃xff0c;而HTML用于格式化并显示数据。但XML不仅仅用于Web应用&＃xff0c;由于XML能有效地表示结构化数据&＃xff0c;使得XML已经成为计算机软件领域数据交换的标准技术模式之一。通过XML实现数据的标准化、结构化&＃xff0c;解决了在不同平台、不同系统之间的数据结构/模式的差异&＃xff0c;使得数据层在XML技术的支持下统一起来。

   实例&＃xff1a;
   

   &＃xff08;3&＃xff09; Protocol buffers
   Protocol buffers 为 Google 提出的一种跨平台、多语言支持且开源的序列化数据格式。相对于类似的 XML 和 JSON&＃xff0c;Protocol buffers 更为小巧、快速和简单。其语法目前分为proto2和proto3两种格式&＃xff0c;是目前冗余信息最少的一种格式&＃xff0c;需要专门工具进行生成和解析&＃xff0c;生成的内容不具备可读性&＃xff0c;但其高性能的优势&＃xff0c;使得该数据格式成为了一些特定领域的理想选择。。
   相对于传统的 XML 和 JSON, Protocol buffers 的优势主要在于&＃xff1a;更加小、更加快。对于自定义的数据结构&＃xff0c;Protobuf 可以通过生成器生成不同语言的源代码文件&＃xff0c;读写操作都非常方便。
   假设现在有下面 JSON 格式的数据:
   
   使用 JSON 进行编码&＃xff0c;得出byte长度为43的的二进制数据&＃xff1a;
   
   如果使用 Protobuf 进行编码&＃xff0c;得到的二进制数据仅有20个字节
   
   &＃xff08;4&＃xff09; 其他
   HTML&＃xff1a;是一种基于标签&＃xff08;TAG&＃xff09;的数据格式&＃xff0c;但领域特定&＃xff0c;是Web服务器和客户端浏览器之间的一种交互手段&＃xff0c;很难用在其他应用中。
   YAML&＃xff1a;与JSON类似&＃xff0c;采用缩进格式&＃xff0c;它进一步减少了冗余信息。不过&＃xff0c;由于兼容性问题&＃xff0c;目前使用领域还比较有限

4. 远程过程调用&＃xff1a;RPC
   
   &＃xff08;1&＃xff09; 介绍
   远程过程调用&＃xff08;英语&＃xff1a;Remote Procedure Call&＃xff0c;缩写为 RPC&＃xff09;是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序&＃xff0c;而程序员无需额外地为这个交互作用编程。如果涉及的软件采用面向对象编程&＃xff0c;那么远程过程调用亦可称作远程调用或远程方法调用&＃xff0c;例&＃xff1a;Java RMI。
   &＃xff08;2&＃xff09; 基本原理
   从发起远程调用到接收到数据返回结果&＃xff0c;大致过程是&＃xff1a;
   1&＃xff09;服务消费方&＃xff08;client&＃xff09;调用以本地调用方式调用服务&＃xff1b;
   2&＃xff09;client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体&＃xff1b;
   3&＃xff09;client stub找到服务地址&＃xff0c;并将消息发送到服务端&＃xff1b;
   4&＃xff09;server stub收到消息后进行解码&＃xff1b;
   5&＃xff09;server stub根据解码结果调用本地的服务&＃xff1b;
   6&＃xff09;本地服务执行并将结果返回给server stub&＃xff1b;
   7&＃xff09;server stub将返回结果打包成消息并发送至消费方&＃xff1b;
   8&＃xff09;client stub接收到消息&＃xff0c;并进行解码&＃xff1b;
   9&＃xff09;服务消费方得到最终结果。

   那么rpc就相当于将step2-step8的步骤进行了封装。
   
   &＃xff08;3&＃xff09; 实现一个简单的RPC

5. 非关系型数据库&＃xff1a;Redis/ Memcached/ MongoDB
   Nosql的全称是Not Only Sql&＃xff0c;这个概念早起就有人提出&＃xff0c;在09年的时候比较火。Nosql指的是非关系型数据库&＃xff0c;而我们常用的都是关系型数据库。就像我们常用的mysql&＃xff0c;oralce、sqlserver等一样&＃xff0c;这些数据库一般用来存储重要信息&＃xff0c;应对普通的业务是没有问题的。但是&＃xff0c;随着互联网的高速发展&＃xff0c;传统的关系型数据库在应付超大规模&＃xff0c;超大流量以及高并发的时候力不从心。而就在这个时候&＃xff0c;Nosql应运而生。
   关系型数据库通常有SQL Server&＃xff0c;Mysql&＃xff0c;Oracle等。主流的Nosql数据库有Redis&＃xff0c;Memcache&＃xff0c;MongoDb。大多数的关系型数据库都是付费的并且价格昂贵&＃xff0c;成本较大&＃xff0c;而Nosql数据库通常都是开源的。
   &＃xff08;1&＃xff09; Redis
   支持多种数据结构&＃xff0c;如 string(字符串)、 list(双向链表)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基数估算)
   支持持久化操作&＃xff0c;可以进行aof及rdb数据持久化到磁盘&＃xff0c;从而进行数据备份或数据恢复等操作&＃xff0c;较好的防止数据丢失的手段。
   支持通过Replication进行数据复制&＃xff0c;通过master-slave机制&＃xff0c;可以实时进行数据的同步复制&＃xff0c;支持多级复制和增量复制&＃xff0c;master-slave机制是Redis进行HA的重要手段。
   单线程请求&＃xff0c;所有命令串行执行&＃xff0c;并发情况下不需要考虑数据一致性问题。
   支持简单的事务需求&＃xff0c;但业界使用场景很少&＃xff0c;并不成熟&＃xff0c;既是优点也是缺点。
   Redis在string类型上会消耗较多内存&＃xff0c;可以使用dict(hash表)压缩存储以降低内存耗用。
   &＃xff08;2&＃xff09; Memcached
   Memcached可以利用多核优势&＃xff0c;单实例吞吐量极高&＃xff0c;可以达到几十万QPS(取决于key、value的字节大小以及服务器硬件性能&＃xff0c;日常环境中QPS高峰大约在4-6w左右)。适用于最大程度扛量。支持直接配置为session handle。
   只支持简单的key/value数据结构&＃xff0c;不像Redis可以支持丰富的数据类型。
   无法进行持久化&＃xff0c;数据不能备份&＃xff0c;只能用于缓存使用&＃xff0c;且重启后数据全部丢失。
   无法进行数据同步&＃xff0c;不能将MC中的数据迁移到其他MC实例中。
   Memcached内存分配采用Slab Allocation机制管理内存&＃xff0c;value大小分布差异较大时会造成内存利用率降低&＃xff0c;并引发低利用率时依然出现踢出等问题。需要用户注重value设计。
   &＃xff08;3&＃xff09; MongoDB
   更高的写负载&＃xff0c;MongoDB拥有更高的插入速度。
   处理很大的规模的单表&＃xff0c;当数据表太大的时候可以很容易的分割表。
   高可用性&＃xff0c;设置M-S不仅方便而且很快&＃xff0c;MongoDB还可以快速、安全及自动化的实现节点(数据中心)故障转移。
   快速的查询&＃xff0c;MongoDB支持二维空间索引&＃xff0c;比如管道&＃xff0c;因此可以快速及精确的从指定位置获取数据。MongoDB在启动后会将数据库中的数据以文件映射的方式加载到内存中。如果内存资源相当丰富的话&＃xff0c;这将极大地提高数据库的查询速度。
   非结构化数据的爆发增长&＃xff0c;增加列在有些情况下可能锁定整个数据库&＃xff0c;或者增加负载从而导致性能下降&＃xff0c;由于MongoDB的弱数据结构模式&＃xff0c;添加1个新字段不会对旧表格有任何影响&＃xff0c;整个过程会非常快速。
   不支持事务。MongoDB占用空间过大 。
   MongoDB没有成熟的维护工具。
   &＃xff08;4&＃xff09; 比较
   三者的性能都比较高&＃xff0c;总的来讲&＃xff1a;Memcache和Redis差不多&＃xff0c;要高于MongoDB。
   memcache数据结构单一。redis丰富一些&＃xff0c;数据操作方面&＃xff0c;redis更好一些&＃xff0c;较少的网络IO次数。mongodb支持丰富的数据表达&＃xff0c;索引&＃xff0c;最类似关系型数据库&＃xff0c;支持的查询语言非常丰富。
   redis&＃xff1a;数据量较小的更性能操作和运算上。
   memcache&＃xff1a;用于在动态系统中减少数据库负载&＃xff0c;提升性能;做缓存&＃xff0c;提高性能(适合读多写少&＃xff0c;对于数据量比较大&＃xff0c;可以采用sharding)。
   MongoDB:主要解决海量数据的访问效率问题。

6. 关系型数据库&＃xff1a;Mysql
   MySQL 是最流行的关系型数据库管理系统&＃xff0c;在 WEB 应用方面 MySQL 是最好的 RDBMS(Relational Database Management System&＃xff1a;关系数据库管理系统)应用软件之一。
   &＃xff08;由于专业课程数据库原理中已经学习过&＃xff0c;这里不做进一步描述&＃xff09;

7. 消息队列: Kafka/ RabbitMQ/ ZeroMQ
   消息队列&＃xff08;Message Queue&＃xff09;&＃xff0c;是分布式系统中重要的组件&＃xff0c;其通用的使用场景可以简单地描述为&＃xff1a;

   当不需要立即获得结果&＃xff0c;但是并发量又需要进行控制的时候&＃xff0c;差不多就是需要使用消息队列的时候。

   消息队列主要解决了应用耦合、异步处理、流量削锋等问题。
   当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等&＃xff0c;而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
   &＃xff08;1&＃xff09; Kafka
   Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)&＃xff0c;&＃xff0c;之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性&＃xff0c;可复制和可容错都是其不错的特性。

   主要特性&＃xff1a;

   1. 快速持久化&＃xff0c;可以在O(1)的系统开销下进行消息持久化&＃xff1b;
   2. 高吞吐&＃xff0c;在一台普通的服务器上既可以达到10W/s的吞吐速率&＃xff1b;
   3. .完全的分布式系统&＃xff0c;Broker、Producer、Consumer都原生自动支持分布式&＃xff0c;自动实现负载均衡&＃xff1b;
   4. 支持同步和异步复制两种HA&＃xff1b;
   5. 支持数据批量发送和拉取&＃xff1b;
   6. zero-copy&＃xff1a;减少IO操作步骤&＃xff1b;
   7. 数据迁移、扩容对用户透明&＃xff1b;
   8. 无需停机即可扩展机器&＃xff1b;
   9. 其他特性&＃xff1a;严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制&＃xff1b;

   &＃xff08;2&＃xff09; RabbitMQ
   RabbitMQ 2007年发布&＃xff0c;是一个在AMQP(高级消息队列协议)基础上完成的&＃xff0c;可复用的企业消息系统&＃xff0c;是当前最主流的消息中间件之一。

   主要特性&＃xff1a;

   1. 可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制&＃xff1b;
   2. 灵活的路由&＃xff1a; 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求&＃xff0c;可以将这些交换机组合起来使用&＃xff0c;你甚至可以实现自己的交换机类型&＃xff0c;并且当做RabbitMQ的插件来使用&＃xff1b;
   3. 消息集群&＃xff1a;在相同局域网中的多个RabbitMQ服务器可以聚合在一起&＃xff0c;作为一个独立的逻辑代理来使用&＃xff1b;
   4. 队列高可用&＃xff1a;队列可以在集群中的机器上进行镜像&＃xff0c;以确保在硬件问题下还保证消息安全&＃xff1b;
   5. 多种协议的支持&＃xff1a;支持多种消息队列协议&＃xff1b;
   6. 服务器端用Erlang语言编写&＃xff0c;支持只要是你能想到的所有编程语言&＃xff1b;
   7. 管理界面: RabbitMQ有一个易用的用户界面&＃xff0c;使得用户可以监控和管理消息Broker的许多方面&＃xff1b;
   8. 跟踪机制&＃xff1a;如果消息异常&＃xff0c;RabbitMQ提供消息跟踪机制&＃xff0c;使用者可以找出发生了什么&＃xff1b;
   9. 插件机制&＃xff1a;提供了许多插件&＃xff0c;来从多方面进行扩展&＃xff0c;也可以编写自己的插件&＃xff1b;

   &＃xff08;3&＃xff09; ZeroMQ
   ZeroMQ&＃xff08;也称为 ØMQ&＃xff0c;0MQ 或 zmq&＃xff09;是一个可嵌入的网络通讯库&＃xff08;对 Socket 进行了封装&＃xff09;。 它提供了携带跨越多种传输协议&＃xff08;如&＃xff1a;进程内&＃xff0c;进程间&＃xff0c;TCP 和多播&＃xff09;的原子消息的 sockets 。 有了ZeroMQ&＃xff0c;我们可以通过发布-订阅、任务分发、和请求-回复等模式来建立 N-N 的 socket 连接。 ZeroMQ 的异步 I / O 模型为我们提供可扩展的基于异步消息处理任务的多核应用程序。 它有一系列语言API&＃xff08;几乎囊括所有编程语言&＃xff09;&＃xff0c;并能够在大多数操作系统上运行。

   传统的 TCP Socket 的连接是1对1的&＃xff0c;可以认为“1个 socket &＃61; 1个连接”&＃xff0c;每一个线程独立维护一个 socket 。但是 ZMQ 摒弃了这种1对1的模式&＃xff0c;ZMQ的 Socket 可以很轻松地实现1对N和N对N的连接模式&＃xff0c;一个 ZMQ 的 socket 可以自动地维护一组连接&＃xff0c;用户无法操作这些连接&＃xff0c;用户只能操作套接字而不是连接本身。所以说在 ZMQ 的世界里&＃xff0c;连接是私有的。

   主要特性&＃xff1a;

   1. 支持高并发的异步 Socket 框架
   2. 协议比 TCP 更快、适用于大型集群和分布式计算
   3. 提供多种消息传递机制&＃xff0c;如 inproc/IPC/TCP/multicast 等
   4. 内置丰富的组合模式&＃xff0c;可用于简化大型分步式计算架构
   5. 提供异步 I/O 模式&＃xff0c;适用于可扩展的多核应用开发
   6. 拥有活跃的开发者社区提供技术支持&＃xff0c;发展相当迅速
   7. 支持超过 30 种的编程语言&＃xff0c;如 C/C&＃43;&＃43;/Java/.NET/Python/PHP 等
   8. 良好的跨平台性&＃xff0c;支持多种 OS&＃xff0c;如 Linux/Windows/OS X 等
   9. 拥有 iMatix 公司的商业级别支持&＃xff0c;却是完全免费的