快乐成长



每天进步一点点

   首页 

 课程体系 

 限时优惠 

 培训细则 

 培训师资 

 讲故事学编程 

 资料 

 儿童计算机 

 原创 

 从0开始学编程 

BookKeeper 原理浅谈

  categories:资料  author:

接着之前的一篇文章 BookKeeper 集群搭建及使用，本文是 BookKeeper 系列的第二篇，短期来看应该也是最后一篇，本篇文章主要聚焦于 BookKeeper 内核的实现机制上，会从 BookKeeper 的基本概念、架构、读写一致性实现、读写分离实现、容错机制等方面来讲述，因为我并没有看过 BookKeeper 的源码，所以这里的讲述主要还是从原理、方案实现上来介绍，具体如何从解决方案落地到具体的代码实现，有兴趣的可以去看下 BookKeeper 的源码实现。

BookKeeper 基础

正如 Apache BookKeeper 官网介绍的一样：A scalable, fault-tolerant, and low-latency storage service optimized for real-time workloads。BookKeeper 的定位是一个可用于实时场景下的高扩展性、强容错、低延迟的存储服务。Pulsar-Cloud Native Messaging & Streaming – 示说网 中也做了一个简单总结：

  1. 低延迟多副本复制：Quorum Parallel Replication；
… 阅读全文

RabbitMQ的应用场景以及基本原理介绍

  categories:资料  author:

1.背景

RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。

2.应用场景

2.1异步处理

场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式
(1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.
这里写图片描述
(2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。
这里写图片描述
假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回.
(3)消息队列
引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理
这里写图片描述
由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。

2.2 应用解耦

场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.
这里写图片描述
这种做法有一个缺点:

  • 当库存系统出现故障时,订单就会失败。(这样马云将少赚好多好多钱^ ^)
  • 订单系统和库存系统高耦合.
    引入消息队列
    这里写图片描述
  • 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
  • 库存系统:订阅下单的消息,获取下单消息,进行库操作。
    就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了).

流量削峰

流量削峰一般在秒杀活动中应用广泛
场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。
作用:
1.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为什么秒杀一次都没有成功过呢^^)
2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)
这里写图片描述
1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.
2.秒杀业务根据消息队列中的请求信息，再做后续处理.

3.系统架构

这里写图片描述
几个概念说明:
Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,
Exchange：消息交换机,它指定消息按什么规则,路由到哪个队列。
Queue:消息的载体,每个消息都会被投到一个或多个队列。
Binding:绑定，它的作用就是把exchange和queue按照路由规则绑定起来.
Routing

… 阅读全文

RabbitMQ 作用及模式

  categories:资料  author:

RabbitMQ 作用

你好！ 你知道RabbitMQ是什么吗，是干什么用的呢，就让我们来学习一下吧。

1.什么是RabbitMQ

RabbitMQ采用了AMQP高级信息消息队列协议的一种消息对列技术，特点就是消费并不需要确保提供方的存在，大大的实现了对服务之间的高度解耦

2.为什么要用RabbitMQ

1.在分布式系统下具备异步，削峰，负载均衡等一系列的功能。
2.拥有持久化的机制，进程信息，队列中的信息也可以保存下来。
3.实现消费者和生产者之间的解耦。
4.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。
  • 3.使用场景
1. 服务见异步通信
2. 顺序消费
3. 定时任务
4. 请求削峰
  • 1
  • 2
  • 3
  • 4

4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息

发送方：
将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。
  • 1
  • 2

一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
接受方：
接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。
这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

… 阅读全文

RabbitMQ快速入门（详细）

  categories:资料  author:

在介绍RabbitMQ之前，我们先来看下面一个电商项目的场景：

  • 商品的原始数据保存在数据库中，增删改查都在数据库中完成。
  • 搜索服务数据来源是索引库（Elasticsearch），如果数据库商品发生变化，索引库数据不能及时更新。
  • 商品详情做了页面静态化处理，静态页面数据也不会随着数据库商品更新而变化。

如果我们在后台修改了商品的价格，搜索页面和商品详情页显示的依然是旧的价格，这样显然不对。该如何解决？  

我们可能会想到这么做：

  • 方案1：每当后台对商品做增删改操作，同时修改索引库数据及更新静态页面。
  • 方案2：搜索服务和商品页面静态化服务对外提供操作接口，后台在商品增删改后，调用接口。

这两种方案都有个严重的问题：就是代码耦合，后台服务中需要嵌入搜索和商品页面服务，违背了微服务的独立原则。

这时，我们就会采用另外一种解决办法，那就是消息队列！

商品服务对商品增删改以后，无需去操作索引库和静态页面，只需向MQ发送一条消息（比如包含商品id的消息），也不关心消息被谁接收。 搜索服务和静态页面服务监听MQ，接收消息，然后分别去处理索引库和静态页面（根据商品id去更新索引库和商品详情静态页面）。

什么是消息队列

MQ全称为Message Queue，即消息队列。“消息队列”是在消息的传输过程中保存消息的容器。它是典型的：生产者、消费者模型。生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，这样就实现了生产者和消费者的解耦。

 

开发中消息队列通常有如下应用场景：

1、任务异步处理：

高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。减少了应用程序的响应时间。

2、应用程序解耦合：

MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

 

AMQP和JMS

MQ是消息通信的模型，并发具体实现。现在实现MQ的有两种主流方式：AMQP、JMS。

两者间的区别和联系：

  • JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
  • JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
  • JMS规定了两种消息模型；而AMQP的消息模型更加丰富

常见MQ产品

… 阅读全文

Pulsar初入门（一）

  categories:资料  author:

Pulsar初入门（一）

参考–Apache-Pulsar官网—http://pulsar.apache.org/

-选择pulsar而不是Kafka的7个原因—https://kafkaesque.io/7-reasons-we-choose-apache-pulsar-over-apache-kafka/

-选择pulsar而不是Kafka的7个原因–infoQ中文版–https://baijiahao.baidu.com/s?id=1634132982881230076&wfr=spider&for=pc

-推荐阅读—–CSDN网友/Pulsar官网文档翻译计划参与者–稀有气体–Kafka的时代已经过去了，未来是Pulsar的吗？等系列文章

简介:

Apache Pulsar是一个开源的分布式的pub-sub消息系统，最初是雅虎创建的，现在是Apache Software Foundation的一部分。

关于pulsar：

1.pulsar函数，使用开发人员友好的API部署轻量级计算逻辑，无需运行自己的流处理引擎

2.低延迟，耐用-设计用于大规模的低延迟发布（<5ms），具有强大的耐用性保障

3.持久存储，基于Apache Bookkeeper的持久消息存储。提供写和读操作之间的IO隔离。

4.生产中证明，Pulsar在雅虎生产超过3年，每秒百万条消息设计百万个主题

5.地域复制，跨地理位置，异地数据中心复制支持

6.客户端库。灵活的消息传递模型，支持java，c++，py，Go

7.水平扩展，水平无缝扩展到数百万个节点

8多租户，原生支持多租户，支持隔离，验证，授权和配额

9可操作性，REST Admin API ，用于配置管理，工具和监视。可以部署在本地和k8s上。

tips：

>多种订阅模式（独占，共享和failover）–默认独占

>broker无状态

>数据老化时，分层存储可以将数据从hot  /   warm存储卸载到cold  /  longterm存储（s3，GCS）

架构：

èå²æç»æå¾

一、Messaging Concepts(消息概念)

pulsar基于pub-sub模式，类似于Kafka(支持点对点和pub-sub)和其它的消息系统。

Messages是Pulsar的基本”单位“，它们是生产者向主题发布的内容以及消费者随后从主题中消费多的内容(并在消息处理时确认)。Messages类似于邮政系统中的信件。

Pulsar的消息构成
Component Purpose
… 阅读全文


快乐成长 每天进步一点点      京ICP备18032580号-1