Category Archives: Backend

verynginx-web防火墙

VeryNginx 转载：https://github.com/alexazhou/VeryNginx VeryNginx 是一个功能强大而对人类友好的 Nginx 扩展程序. 提示 v0.2 版本之后，控制台入口被移动到了 /verynginx/index.html 介绍 VeryNginx 基于 lua_nginx_module(openrestry) 开发，实现了高级的防火墙、访问统计和其他的一些功能。 集成在 Nginx 中运行，扩展了 Nginx 本身的功能，并提供了友好的 Web 交互界面。 VeryNginx在线实例 用户名 / 密码: verynginx / verynginx 详细配置说明见：VeryNginx Github WiKi Nginx 运行状态分析 每秒请求数 响应时间 网络流量 网络连接数 自定义行为 VeryNginx 包含强大的自定义功能，可以做很多事情 自定义行为包含两部分， Matcher 和 Action 。 Matcher 用来对请求进行匹配， Action 为要执行的动作 这样的优势在于把所有的前置判断整合在Matcher里一起来实现了，使复杂(组合)规则的实现变成了可能 Matcher 一个 Matcher 用来判断一个 Http 请求是否符合指定的条件， 一个 Matcher 可以包含一个或者多个约束条件，目前支持以下几种约束： Client IP Host UserAgent URI Referer Request Args 当一个请求没有违反 Matcher 中包含的全部条件时，即命中了这个 Matcher Action 每个 Action 会引用一个 Matcher ，当 Matcher 命中时， Action 会被执行 目前已经实现了以下 Action Scheme Lock 将访问协议锁定为 Https 或者 Http Redirect 对请求进行重定向 URI Rewrite 对请求的 URI […]

maven install时报错Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test

事故现场： 解决办法： 一是命令行，

二是写入pom文件

  from:https://www.cnblogs.com/lxcy/p/8279899.html

师说开源CMS 在IDEA 下运行起来的方法

1.git 项目到仓库中。 2.运行maven 导入JAR包 3.配置项目project structure（CTRL+ALT+SHIFT+S） project settings 第一项 Project compiler output 路径 : D:\git\CMS\target\shishuocms-2.0.1\WEB-INF\classes 第二项 Modules: Paths 选择第一个 Inherit project compile output path 复制 applicationContext.xml 、 log4j.properties、 shishuocms.properties 到 target/shishuocms-2.0.1/WEB-INF/classes下面。 别忘了修改shishuocms.properties的数据库连接配置。 ———————————————— 版权声明：本文为CSDN博主「matt0614」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/matt0614/article/details/44972539

CD基金会、Jenkins、Jenkins X、Spinnaker和Tekton的常问问题

FAQ 什么是持续交付（CD）？ CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。微服务、云原生架构的兴起引发了持续交付实践的必然结果。这与CI/CD有关，其中包括持续集成（CI） – 将所有开发者工作副本一天多次合并到共享主线的做法。 宣布了什么？ CDF（Continuous Delivery Foundation，持续交付基金会）是一个新的、中立的组织，将发展和维持一个开放的持续交付生态系统。它将提供统一的治理和与供应商中立的管理，以及对资金和运营的监督。CD基金会的第一批项目是Jenkins、Jenkins X、Spinnaker和Tekton。 为什么CD社区组成基金会。为什么需要？ 整个行业都迫切需要围绕管道、工作流程和其他CI/CD领域合作定义行业规范，并为CI/CD工具提供基础支持。例如，Jenkins社区正在寻求一个“全方位服务”的基金会来托管Jenkins（最受欢迎的CI/CD项目之一），并构建一个增强协作的平台。还需要一个全行业的中立DevOps/CD会议。 这是否代表了云原生态系统的转变？ 是的，市场已转向容器化和云原生技术，因此CI/CD系统、DevOps和相关工具的生态系统发生了根本性的变化。CNCF云原生互动景观展示了CI/CD领域的多样性，以及在该领域中活跃的众多项目和供应商。 通过建立供应商中立的持续交付基金会，业界顶级开发者、最终用户和供应商可以将CI/CD作为方法，定义/记录最佳实践以及创建培训材料，以使全球任何软件开发团队能够交付代码更改更快、更可靠、无论它们是否为云原生。 开发者为何要关心？ CI/CD项目目前面临的挑战，包括工具复杂性和管道和其他CI/CD工具缺乏行业标准化，正在抑制增长和创新。由于缺乏中立的法律实体和强有力的治理，项目很难吸引新开发者和组织的宝贵支持。项目维护者和开发者花费大量时间和金钱处理安全程序和监督等方面的变通方法。这使人们不再关注新的发展和创新。拥有广泛行业支持的基金会将能够更快地定义行业规范，并为跨项目协作创造更多机会，以改善开发者的工具。 谁用CD？ CD广泛应用于云计算、企业IT，并且正在迅速扩展到其他顶级行业垂直领域。例如，在网络运营商与供应商并肩工作，开发CI/CD工具，使开发者能够直接与上游项目的分支合作 – 大幅缩短实施新功能的时间，并解决数月到数天的错误。使用云原生技术（如Kubernetes）时，设置CI/CD管道将加快发布生命周期。这使开发者每天可以多次发布；让团队灵活到足以快速迭代。 CDF如何与渐进式交付相关？ 渐进式交付（Progressive delivery）是现代持续交付技术的一种形式，例如灰度发布、功能标记、A/B测试、经过验证的部署组等。渐进式交付技术和技术与持续交付密切相关。有关渐进式交付的更多信息，请阅读James Governor关于此主题的Redmonk博客：https://redmonk.com/jgovernor… 这将如何影响开源软件的开发？ 持续交付可提高软件开发团队的速度、生产力和可持续性。CDF促进行业顶级开发者、最终用户和供应商之间的合作，以确保CD方法的软件工程充分发挥其潜力，推进开源软件开发。 哪些项目将包含在CDF中？ CDF正在推出四个项目：Jenkins、Jenkins X、Spinnaker和Tekton，还有更多感兴趣的项目正在筹备中。我们邀请人们关注CDF技术监督委员会（“TOC”），该委员会将在未来做出项目决策：https://github.com/cdfoundati…。 我是否必须是成员才可以贡献到CDF项目？ 绝对不是，CDF中的开源项目或任何Linux基金会计划的技术贡献都不需要成员资格。组织作为成员加入CDF，因为它们希望在持续交付模型和最佳实践的增长和发展中扮演积极的角色，而不只是支持CDF中的开放源码项目。如果你有兴趣加入，请参阅https://cd.foundation/members…。 什么是Jenkins？ Jenkins是领先的开源自动化服务器，由大量不断增长的开发者、测试者、设计者和其他对持续集成、持续交付和现代软件交付实践感兴趣的人提供支持。它基于Java虚拟机（JVM），提供超过1,500个插件，可将Jenkins扩展为几乎所有技术软件交付团队使用的自动化服务器。2019年，Jenkins有超过了200,000个已知安装，使其成为部署最广泛的自动化服务器。 什么是Jenkins X？ Jenkins X是Kubernetes上现代云应用程序的开源CI/CD解决方案。Jenkins X提供管道自动化、内置GitOps和预览环境，以帮助团队协作并加速他们的软件交付。Jenkins X使用最好的OSS工具自动化Kubernetes的CI + CD，如Jenkins、Tekton、Prow、SkaffoldKaniko和Helm。 为什么Jenkins和Jenkins X成为CDF的一员？ Jenkins和Jenkins X将成为与技术兴趣相关的中立社区的一部分，并在构建开发者社区和项目治理方面获得帮助。CD基金会还将协助Jenkins和Jenkins X的营销和文档工作。 这对现有Jenkins用户有何影响？ 将Jenkins和Jenkins X捐赠给CD基金会将促进行业内开发者、最终用户和供应商之间的更多合作。有关详细信息，请参阅此电子邮件和与Jenkins社区的对话：https://groups.google.com/for… 什么是Tekton？ Tekton是一组用于构建CI/CD系统的共享开源组件。它使持续交付控制平面现代化，并将软件部署的大脑转移到Kubernetes。Tekton的目标是通过供应商中立的开源基金会为CI/CD管道、工作流程和其他构建模块提供行业规范。Tekton的代码在https://github.com/tektoncd/p…。 为什么Tekton成为CDF的一员？为什么Google会捐赠代码？ 作为CDF的创始成员，谷歌正在捐赠Tekton。正如Kubernetes通过提供一组标准的API在云中进行交互而彻底改变了应用程序开发，Google的目标是通过CD基金会为DevOps从业者提供相同的优势。CDF将提供行业规范、安全、实用和可扩展的持续交付构建块，可用于在任何地方部署代码。 Tekton对knative build的影响是什么？ 从第1天开始，可插拔性一直是knative的核心功能。将Build与Serving分离的目标是强化这种可插拔性概念。已经对构建系统感到满意的用户可以将其与Knative Serving一起使用。Tekton将继续支持Knative生态系统作为一流的目标环境。Tekton管道将部署到Knative环境。 在可预见的未来，Knative Build将继续作为Knative的一部分，专注于无服务器环境的源到容器工作流程。这两个项目将在标准和界面上保持紧密联系。 什么是Spinnaker？ Spinnaker是云端优先的持续交付平台，最初由Netflix创建，目前由Netflix和Google共同领导。它支持所有主要的云平台和Kubernetes，并得到各个供应商的贡献。Spinnaker通常用于大规模组织，DevOps团队通过提供“黄金路径”（golden path）应用程序部署管道来支持许多开发者。 为什么Google/Netflix将Spinnaker捐赠给CDF？ 随着Spinnaker最近将其治理正式化，将其转移到基金会是社区自然的下一步。Spinnaker设计为持续交付平台，通常与Jenkins结合使用，因此CDF真的是项目的理想之家。 Spinnaker也是一个多组件系统，在概念上与Tekton分享了许多想法 – 看到两个项目在一个基金会上聚集在一起，是将持续交付向前推进的巨大机会。 这对Spinnaker用户有何影响？ Spinnaker作为CDF的一员，社区将有更多机会创建更简单、更强大的端到端体验，并就CI/CD的一套通用标准进行协作。Spinnaker用户在持续交付领域拥有丰富的经验，加入CDF提供了一个与更广泛的社区分享专业知识的绝佳机会。 Spinnaker用户还将受益于CDF社区中广泛的CI/CD知识，他们使用的各种工具之间的一致性，当然还有不断改进的生态系统！ 未来的CI/CD项目进入CDF的过程是怎样？ 其他项目预计将通过其即将成立的技术监督委员会（TOC）加入CDF：https://github.com/cdfoundati…，重点是将CD生态系统整合在一起，围绕可移植性和互操作性构建规范和项目。 CDF的下一步是什么？ 接下来的步骤是启动治理结构。将成立一个理事会、技术和外联/营销委员会。我们计划在未来几个月内实现这一目标，并邀请新成员加入我们的社区。如果你有兴趣加入社区推进CD，请到https://cd.foundation/members…。 CNCF的参与程度，为什么需要一个单独的基金会？ 首先要注意的是，CD适用于整个软件行业，而不仅仅适用于现代云原生应用程序。CNCF（Cloud Native Computing Foundation，云计算本地计算基金会）是CDF的姐妹基金会，拥有自己的治理结构和使命。每个基金会都有不同的使命，由其创始成员和技术专家定义。CNCF认为大多数与CD相关的工具超出了他们专注的云原生定义的范围，后者主要关注容器化、微服务、服务网格和编排。CDF超越云和容器，包括传统基础设施、移动、物联网、裸机等。CNCF和CDF都属于较大的Linux基金会旗下，计划在许多领域进行合作，包括同场会议。例如，CDF将于5月20日在西班牙巴塞罗那的KubeCon + CloudNativeCon Europe 2019举办持续交付峰会（CDS）活动。 CDF如何支持或与DevOps领域的其他玩家合作？ CDF的使命是为开发者、最终用户和供应商提供一个中立的家庭，以便在CI/CD方法上进行协作。在这方面，CDF将通过发布关注可移植性的最佳实践、培训材料和行业指南来支持DevOps从业者。 有兴趣成为这个新基金会成员并制定治理方案的组织应到CDF加入的页面。开发者可以在此处注册CD基金会邮件列表：info@lists.cd.foundation。任何有兴趣加入CDF的项目都可以联系技术监督委员会（TOC）：https://github.com/cdfoundati…。 KubeCon […]

CMMI5的一些资料

Linux chkconfig命令

Linux chkconfig命令用于检查，设置系统的各种服务。 这是Red Hat公司遵循GPL规则所开发的程序，它可查询操作系统在每一个执行等级中会执行哪些系统服务，其中包括各类常驻服务。 语法

  参数： --add 　增加所指定的系统服务，让chkconfig指令得以管理它，并同时在系统启动的叙述文件内增加相关数据。 --del 　删除所指定的系统服务，不再由chkconfig指令管理，并同时在系统启动的叙述文件内删除相关数据。 --level<等级代号> 　指定读系统服务要在哪一个执行等级中开启或关毕。 实例 列出chkconfig所知道的所有命令。

  开启服务。

  关闭服务

    from:https://www.runoob.com/linux/linux-comm-chkconfig.html

protobuf-net C# 7.0 中不支持功能“默认文本”。请使用 7.2 或更高的语言版本。

VS工程导入protobuf-net（https://github.com/mgravell/protobuf-net） 源码，报错。 解决方法：项目右键属性 —> 生成 —> 找到最下面的高级按钮，点击高级按钮 —> 常规 —> 语言版本 —> 选择 C#最新次要版本，或者比当前版本更高的版本即可，点击确定，然后保存即可。   from:https://blog.csdn.net/iningwei/article/details/86490259

Spinnaker 介绍 – Netflix 的持续交付平台

Spinnaker 是 Netflix 在2015年开源的一款持续交付平台，它继承了 Netflix 上一代集群和部署管理工具 Asgard：Web-based Cloud Management and Deployment的优点，同时根据公司业务以及技术的的发展抛弃了一些过时的设计：提高了持续交付系统的可复用性，提供了稳定可靠的API，提供了对基础设施和程序全局性的视图，配置、管理、运维都更简单，而且还完全兼容 Asgard，总之对于 Netflix 来说 Spinnaker 是更牛逼的持续交付平台。 在深入了解 Spinnaker 之前，先扯一扯 Netflix 的技术文化：这是一家全面拥抱云的公司，据报道数据中心完全部署在 AWS 上，是 AWS 的超级大客户。在上云后他们发现故障仍然避免不了，为了更加从容的应对这些故障，就搞了一个工具 Chaos Monkey 会随机停止生产环境中的虚拟机，通过观察系统在真实故障中的表现来确保程序的健壮性，也通过实战来验证各种高可用技术是否靠谱。接着冒出了 Chaos Gorilla，会停止一整个可用域中的所有机器；最后还有Chaos Kong，直接停掉一整个 Region，非常有挑战精神（丧心病狂）。 为了更好的观察系统在故障时的情况，还研发了全局可视化系统，代号 Flux，可以将整个系统的逻辑架构和各服务之间的流量可视化在大屏幕上，效果图如下： 他们每个月有一个活动：将一个 Region 里的机器全部关掉，看 Netflix 服务是否正常。有兴趣看视频的可以移步这里。 另外，Netflix 除了云服务，还有自建CDN，即 Open Connect 项目，这个项目的边缘设备是地地道道的物理设备，并且从硬件到软件全部是自己定制的。关于 Open Connect 的详细介绍，以及使用的技术栈可以看 Netflix 的分享，还有他们如何做 CDN 监控的。 主要功能 回到 Spinnaker，他主要管理 Netflix 的云服务，并不管理 OpenConnect 相关的设备和服务。Spinnaker 是基于云的 CD 平台，提供快速、可靠、稳定的软件变更服务。主要包含两类功能：集群管理（Cluster management）和部署管理（deployment management）。 1. 集群管理 集群管理主要用于管理云资源，Spinnaker 所说的“云”可以理解成 AWS，即主要是 IaaS 的资源，比如 OpenStack，Google云，微软云等，后来还支持了容器，但是管理方式还是按照管理基础设施的模式来设计的。 Spinnaker 中管理如下资源： Server Group：最基本的逻辑资源，包括了若干使用相同配置和镜像的虚拟机，若干负载均衡（load balancer），以及安全组。 安全组规则（Security Group）：就是 AWS 中的安全组，可以理解成防火墙。 负载均衡（Load Balancer）：AWS 中的 ELB，也可能是安装在虚拟机中的负载均衡。 2. 部署管理 管理部署流程是 Spinnaker 的核心功能，他负责将软件包（可能是手工创建的或者 jenkins 创建的）打成一个镜像，用这个镜像生成对应的虚拟机，让服务真正运行起来： pipeline 在 Spinnaker 中一个部署流程叫做pipeline，由若干个操作组成，每个操作又叫做一个 stage。触发一个 […]

基于IdentityServer4 实现.NET Core的认证授权

目录 IdentityServer4是什么？ OpenID Connect 和 OAuth2.0是什么 Authentication 和 Authorization的区别 OAuth2.0的原理 IdentityServer4能做什么 IdentityServer4定义的基本术语 IdentityServer4的简单示例 IdentityServer4是什么？ IdentityServer4是基于ASP.NET Core实现的认证和授权框架，是对OpenID Connect和OAuth 2.0协议的实现。 OpenID Connect 和 OAuth2.0是什么 OpenID Connect: OpenID Connect由OpenID基金会于2014年发布的一个开放标准, 是建立在OAuth 2.0协议上的一个简单的身份标识层, OpenID Connect 兼容 OAuth 2.0. 实现身份认证（Authentication） 参考资料：https://openid.net/connect/ OpenID Connect文档：https://openid.net/specs/openid-connect-discovery-1_0.html OAuth2.0: OAuth2.0是一个开放的工业标准的授权协议（Authorization），它允许用户授权让第三方应用直接访问用户在某一个服务中的特定资源，但不提供给第三方账号及密码信息 参考资料：https://www.cnblogs.com/xiandnc/p/9763121.html OAuth2.0 文档：https://tools.ietf.org/html/rfc6749#page-73 Authentication 和 Authorization的区别 1 2 authentication: n. 证明；鉴定；证实 authorization: n. 授权，认可；批准，委任 前者是身份识别，鉴别你是谁；后者是授权许可，告诉你可以做什么。 举个例子：你吭哧吭哧写了一天的代码，急于回家吃上一口媳妇做的热饭。当你走到小区门口的时候你需要刷小区的门禁卡才能进入到小区里面，然后再找到你家在哪一栋楼，几单元几号，然后掏出钥匙开门才能回到家。在这个过程中刷小区的门禁就是认证你是这个小区的人，拿你家的钥匙开门就是授权的过程，如果你的认证不通过，那就不存在授权。 OAuth2.0的原理 我们先来了解一下OAuth2.0中的几个关键概念： 资源所有者（Resource Owner）： 一个能够访问受保护资源的实体。当资源所有者是一个人时，它被称为终端用户 资源服务器（Resource Server）： 托管受保护资源的服务器，能够使用访问令牌接受和响应受保护的资源请求 客户端（Client）： 代表资源所有者和其授权的应用程序来保护资源请求。术语客户端并不意味着任何特定的实现特征（例如，应用程序是否在服务器、桌面或其他设备上执行） 授权服务器（Authorization Server）： 在成功验证资源所有者并获得授权之后，服务器向客户端发出访问令牌。（授权服务器是用来管理Resource Owner，Resource Server，Client的中间人） 场景：小李想要打印（美图快印）自己三年来发布在新浪微博相册中和女朋友的照片，有没有什么方法他既不告诉工作人员自己的新浪微博用账号和密码又能够方便快捷的把照片给到美图快印呢？（排除存U盘这种手工操作）   Authorization Server和Resource Server可以使独立的服务提供商，也可以是在一起的，比如例子中新浪微博既作授权服务器也用来存储用户的图片资源。我们可以看到OAuth2解决的问题是：通过Authorization Server可以提供一个访问的凭据（token）给client（美图快印的工作人员），使得client可以在不知道Resource Owner以及Resource Server的用户名和密码的情况下访问到Resource Owner受保护的资源，它是一个完美的中间人。 OAuth2.0详细内容请参考：https://www.cnblogs.com/xiandnc/p/9763121.html IdentityServer4能做什么 用户认证服务 基于OpenID Connect实现的独立的认证服务实现对多平台（web, native, mobile, services）的集中认证 API访问授权 […]

Kafka学习之路 （一）Kafka的简介

目录 一、简介 1.1　概述 1.2　消息系统介绍 1.3　点对点消息传递模式 1.4　发布-订阅消息传递模式 二、Kafka的优点 2.1　解耦 2.2　冗余（副本） 2.3　扩展性 2.4　灵活性&峰值处理能力 2.5　可恢复性 2.6　顺序保证 2.7　缓冲 2.8　异步通信 三、常用Message Queue对比 3.1　RabbitMQ 3.2　Redis 3.3　ZeroMQ 3.4　ActiveMQ 3.5　Kafka/Jafka 四、Kafka中的术语解释 4.1　概述 4.2　broker 4.3　Topic 4.3　Partition 4.4　Producer 4.5　Consumer 4.6　Consumer Group 4.7　Leader 4.8　Follower   正文 回到顶部 一、简介 1.1　概述 Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是：日志收集系统和消息系统。 Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out:支持在线水平扩展 1.2　消息系统介绍 一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。 1.3　点对点消息传递模式 在点对点消息系统中，消息持久化到一个队列中。此时，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。这种架构描述示意图如下： 生产者发送一条消息到queue，只有一个消费者能收到。 1.4　发布-订阅消息传递模式 在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。该模式的示例图如下： 发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。 回到顶部 二、Kafka的优点 2.1　解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2.2　冗余（副本） 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 2.3　扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。 2.4　灵活性&峰值处理能力 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 2.5　可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 2.6　顺序保证 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。 2.7　缓冲 在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。 2.8　异步通信 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 回到顶部 三、常用Message Queue对比 3.1　RabbitMQ RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。 3.2　Redis Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 3.3　ZeroMQ ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。 3.4　ActiveMQ ActiveMQ是Apache下的一个子项目。 […]