分布式开发

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。 在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用： 降低系统组网复杂度。 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。 1、Kafka主要特点： 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。 支持online和offline的场景。 2、Kafka的架构

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

转载自 https://www.cnblogs.com/luotianshuai/p/5206662.html Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ 2、Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释： 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议

点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》 本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！ 作者 | 李云（花名：至简） 阿里云高级技术专家 导读 ：在即将过去的 2019 年，Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化，但在国内仍出现了一些值得特别关注的事件。比如：阿里巴巴在 双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案，借助 双11 的严苛业务场景完成了规模化落地前的初步技术验证。本文作者将结合自己在阿里巴巴落地实践 Service Mesh 过程中的观察与思考，来和大家进行分享。 Service Mesh 是新瓶装旧酒吗？ 新技术出现时所主张的价值一定会引发相应的探讨，Service Mesh 也不例外。 以往，怀疑 Service Mesh 价值的观点主要有两大类。 第一类 是应用的数量并没有达到一定的规模，在 Service Mesh 增加运维和部署复杂度的情形下，认为所带来的成本和复杂度高于所获得的收益。 从根本上来看，这一类并非真正怀疑 Service Mesh 的价值，而是主张在 Service Mesh 还没有完全成熟和普及的情形下，在未来合适的时机再考虑采纳。当然，我在与外部客户交流时也碰到一些特例，他们即便在应用数很少的情形下，仍希望通过

两大主流开源分布式存储的对比： GlusterFS vs. Ceph 存储世界最近发生了很大变化。十年前，光纤通道SAN管理器是企业存储的绝对标准，但现在的存储必须足够敏捷，才能适应在新的基础架构即服务云环境内运行。 GlusterFS和Ceph是在现代云环境中表现最出色的两个敏捷存储系统。 在讲述GlusterFS和Ceph的相同点和区别之前，我们先谈一谈云环境中敏捷存储的一些关键点。 纵向升级和横向扩展。在云环境中，很容易向服务器添加更多存储空间和扩展可用存储池。Ceph和GlusterFS都符合这一需求，让新的存储设备可以轻松融入现有存储产品环境。 高可用。GlusterFS和Ceph都会使用复制方法将数据同时写入不同存储节点。这种运作模式会增加读写次数，但同时也确保了数据的可用性。以Ceph为例，数据在默认情况会被复制到三个不同的节点，确保数据副本一直可用。 通用的硬件。GlusterFS和Ceph的开发基础都是Linux操作系统(OS)。因此，对于硬件的唯一要求就是：能够正常运行Linux即可。由于几乎任何商品硬件都能运行Linux操作系统，只要选择这些存储技术，这些技术的使用单位就可以大幅节省硬件投入。实际上，有许多公司也正在投资专用于GlusterFS或Ceph的硬件平台，因为专门优化的硬件可以更快速高效地访问存储空间。 去中心化

导入依赖 将所有的依赖都导入到父工程当中，供所有的子工程使用； <dependencies> <!-- https://mvnrepository.com/artifact/org.springframework/spring-beans --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>5.1.5.RELEASE</version> </dependency> <!-- https://mvnrepository.com/artifact/org.springframework/spring-context --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.1.5.RELEASE</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.16</version> </dependency> <dependency>

分布式锁的背景，基于数据库、redis、zookeeper实现分布式锁的原理与优缺点你都知道吗？   为什么要分布式锁、分布式锁的实现方式有哪几种、这几种分布式锁实现方式的优缺点有哪些？阅读完本文后你你应该掌握： 基于数据库实现分布式锁具体步骤是什么，优缺点是什么； 基于Redis实现分布式锁具体步骤是什么，优缺点是什么； 基于Zookeeper实现分布式锁具体步骤是什么，优缺点是什么； 分布式锁诞生的背景   我们在开发 单机应用 的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！   我们现在的应用程序如果只部署一台服务器，那并发量是很差的，如果同时有上万的请求那么很有可能造成服务器压力过大，而瘫痪。   想想双十一 和 三十晚上十点分支付宝红包等业务场景，自然需要用到多台服务器去同时处理这些业务，那么这些服务可能会有上百台同时处理，   但是请我们大家想一想，如果有100台服务器 要处理分红包的业务，现在假设有1亿的红包，1千万个人分，金额随机，那么这个业务场景下是不是必须确保这1千万个人最后分的红包金额总和等于1亿。   如果处理不好 每人分到100万，那马云爸爸估计大年初一，就得宣布破产了 分布式锁应该具备的条件   在分析分布式锁的三种实现方式之前

原文地址： http://www.sohu.com/a/228804309_99940985 我们很高兴地宣布，今天 蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服 自主研发 的 金融级 分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架， 分布式数据库 代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。 蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。 Why（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景， 支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s