konohanaruto

konohanaruto 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织 www.muyesanren.com 编辑
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 该用户太懒什么也没留下

个人动态

konohanaruto 收藏了文章 · 8月28日

使用 Swoole 加速 Laravel

Swoole 是针对PHP的生产级异步编程框架。它是一种用纯C语言编写的PHP扩展,它使PHP开发人员能够在PHP中编写高性能,可扩展的并发TCP,UDP,Unix套接字,HTTP,WebSocket服务,而无需太多的非阻塞I/O编程和Linux内核知识。 你可以将Swoole想象成NodeJS,但是对于PHP来说,性能更高。

为什么要在Swoole上运行Laravel

下图说明了PHP中的生命周期。 正如你所看到的,当你每次运行php脚本时,PHP都需要初始化模块并为你的运行环境启动Zend Engine。 并且你的PHP脚本需要编译为OpCodes以供Zend Engine执行。

但是,这个生命周期需要在每个请求中重复一遍。因为为单个请求创建的环境将在请求过程完成后立即销毁。

换句话说,在传统的PHP生命周期中,它浪费了大量时间为脚本执行构建和销毁资源。 想象一下像 Laravel 这样的框架,需要为一个请求加载多少个文件? 加载文件也有很多I/O消耗。

PHP生命周期

那么如果我们在Swoole之上有一个内置的服务器,并且所有的脚本可以在第一次加载后保存在内存中呢? 这就是我们试图在Swoole上运行Laravel的原因。 Swoole可以成为强大的性能增强器,Laravel提供了优雅的结构和代码使用方式。 这是一个完美的组合!

安装

以下是 swooletw/laravel-swoole 的主要特点:

  • 在Swoole上运行 Laravel/Lumen 应用程序
  • 卓越的性能提升至 30倍
  • 沙箱模式隔离应用程序容器
  • 支持在Laravel中运行WebSocket服务器
  • 支持Socket.io协议
  • 支持Swoole表进行跨进程数据共享

使用Composer安装:

composer require swooletw/laravel-swoole -vvv
这个软件包依赖于Swoole。请确保你的机器具有Swoole扩展。你可以使用此命令快速安装它:pecl install swoole,并访问官方网站获取更多信息。
注意:Swoole目前仅支持Linux和macOS。 Windows服务器不能使用Swoole。

然后,添加服务提供者:

如果你使用的是Laravel,请将服务提供者添加到 config/app.php 中提供者的数组中:

[
    'providers' => [
        SwooleTW\Http\LaravelServiceProvider::class,
    ],
]

如果您使用的是 Lumen,请将以下代码附加到 bootstrap/app.php:

$app->register(SwooleTW\Http\LumenServiceProvider::class);
它支持包自动发现。如果你运行的是Laravel 5.5,则可以跳过此步骤。

启动和运行

现在,你可以运行以下命令来启动Swoole HTTP服务器。

php artisan swoole:http start

然后你可以看到以下消息:

Starting swoole http server...
Swoole http server started: <http://127.0.0.1:1215>

现在你可以在 http://127.0.0.1:1215 上访问你的Laravel应用程序。

基准测试

使用MacBook Air 13,2015进行干净的Lumen 5.5测试。

基准测试工具:wrk

wrk -t4 -c100 http://your.app

Nginx with FPM

Running 10s test @ http://lumen.app:9999
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.14s   191.03ms   1.40s    90.31%
    Req/Sec    22.65     10.65    50.00     65.31%
  815 requests in 10.07s, 223.65KB read
Requests/sec:     80.93
Transfer/sec:     22.21KB

Swoole HTTP Server

Running 10s test @ http://127.0.0.1:1215
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    11.58ms    4.74ms  68.73ms   81.63%
    Req/Sec     2.19k   357.43     2.90k    69.50%
  87879 requests in 10.08s, 15.67MB read
Requests/sec:   8717.00
Transfer/sec:      1.55MB

更多

查看 Github Repo官方文档获取更多信息。

原文地址,请前往 PHPCasts
查看原文

konohanaruto 收藏了文章 · 8月28日

【swoole】结合swoole 和 nsq 的实际应用

集合 swoole 的框架设计

为了减少理解度,我尽量的从源头开始引入

1. nsq

案例中是使用 swoole 结合一个php 框架实现的是 NSQ 订阅功能。

启动命令:

sudo bash /www/webserver/bin/swoole.sh start nsq adminexport

解释上面一个指令,使用 bash 执行一个项目中的脚本。

start 对应启动命令
nsq : 代表对应使用NSQ 服务
adminexport : 对应的是NSQ 的topic

脚本的本质,通过框架的入口文件,根据传参,进入到的不同的消息中间件,及对应的服务

clipboard.png

2. php 订阅

AdminexportService 继承封装好的 SwooleService。 在init方法中,初始化 swoole服务。并且注册回调函数。

clipboard.png

AdminexportService 在重写的 swooleWorkerStart 回调函数中,实现了NSQ 的订阅功能

clipboard.png

NSQ 消息的处理

clipboard.png

  1. 简单封装了重复消息的判断
  2. requeue 没有消费消息的重新投递

3. 引入 swoole

就是构造方法引入 swoole 的实例化
同时,重写 workerStart 的方法。

所以当执行脚本的时候,也就是启动了 对应的swoole 服务。启动了订阅者的客户端。
不断的消费来自nsq topic 的消息

看吧,swoole 其实也很简单。 把它当做一个工具类,拿来用就可以了。 在实现的时候引入它,通过 WorkerStart 处理分发的消息即可。

当然更好的是使用协程。
另外吹一波,协程就是厉害
查看原文

konohanaruto 收藏了文章 · 8月27日

上手了RabbitMQ?再来看看它的交换机(Exchange)吧

人生终将是场单人旅途,孤独之前是迷茫,孤独过后是成长。

楔子

本篇是消息队列RabbitMQ的第三弹。

RabbitMQ的入门RabbitMQ+SpringBoot的整合可以点此链接进去回顾,今天要讲的是RabbitMQ的交换机。

本篇是理解RabbitMQ很重要的一篇,交换机是消息的第一站,只有理解了交换机的分发模式,我们才能知道不同交换机根据什么规则分发消息,才能明白在面对不同业务需求的时候应采用哪种交换机。


祝有好收获,先赞后看,快乐无限。

本文代码:码云地址GitHub地址

1. 🔍Exchange

rabbit架构图

先来放上几乎每篇都要出现一遍的我画了好久的RabbitMQ架构图。

前两篇文中我们一直没有显式的去使用Exchange,都是使用的默认Exchange,其实Exchange是一个非常关键的组件,有了它才有了各种消息分发模式。

我先简单说说Exchange有哪几种类型:

  1. fanoutFanout-Exchange会将它接收到的消息发往所有与他绑定的Queue中。
  2. directDirect-Exchange会把它接收到的消息发往与它有绑定关系且Routingkey完全匹配的Queue中(默认)。
  3. topicTopic-Exchange与Direct-Exchange相似,不过Topic-Exchange不需要全匹配,可以部分匹配,它约定:Routingkey为一个句点号“. ”分隔的字符串(我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词)。
  4. headerHeader-Exchange不依赖于RoutingKey或绑定关系来分发消息,而是根据发送的消息内容中的headers属性进行匹配。此模式已经不再使用,本文中也不会去讲,大家知道即可。

本文中我们主要讲前三种Exchange方式,相信凭借着我简练的文字和灵魂的画技给大家好好讲讲,争取老妪能解。

Tip:本文的代码演示直接使用SpringBoot+RabbitMQ的模式。

2. 📕Fanout-Exchange

先来看看Fanout-ExchangeFanout-Exchange又称扇形交换机,这个交换机应该是最容易理解的。

扇形交换机

ExchangeQueue建立一个绑定关系,Exchange会分发给所有和它有绑定关系的Queue中,绑定了十个Queue就把消息复制十份进行分发。

这种绑定关系为了效率肯定都会维护一张表,从算法效率上来说一般是O(1),所以Fanout-Exchange是这几个交换机中查找需要被分发队列最快的交换机。


下面是一段代码演示:

    @Bean
    public Queue fanout1() {
        return new Queue("fanout1");
    }

    @Bean
    public Queue fanout2() {
        return new Queue("fanout2");
    }

    @Bean
    public FanoutExchange fanoutExchange() {
        // 三个构造参数:name durable autoDelete
        return new FanoutExchange("fanoutExchange", false, false);
    }

    @Bean
    public Binding binding1() {
        return BindingBuilder.bind(fanout1()).to(fanoutExchange());
    }

    @Bean
    public Binding binding2() {
        return BindingBuilder.bind(fanout2()).to(fanoutExchange());
    }

为了清晰明了,我新建了两个演示用的队列,然后建了一个FanoutExchange,最后给他们都设置上绑定关系,这样一组队列和交换机的绑定设置就算完成了。

紧接着编写一下生产者和消费者:

    public void sendFanout() {
        Client client = new Client();

        // 应读者要求,以后代码打印的地方都会改成log方式,这是一种良好的编程习惯,用System.out.println一般是不推荐的。
        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("fanoutExchange",null,client);
        System.out.println("消息发送完毕。");
    }

    @Test
    public void sendFanoutMessage() {
        rabbitProduce.sendFanout();
    }
@Slf4j
@Component("rabbitFanoutConsumer")
public class RabbitFanoutConsumer {
    @RabbitListener(queues = "fanout1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "fanout2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

这两段代码都很好理解,不再赘述,有遗忘的可以去看RabbitMQ第一弹的内容。

其中发送消息的代码有三个参数,第一个参数是Exchange的名称,第二个参数是routingKey的名称,这个参数在扇形交换机里面用不到,在其他两个交换机类型里面会用到。

代码的准备到此结束,我们可以运行发送方法之后run一下了~

项目启动后,我们可以先来观察一下队列与交换机的绑定关系有没有生效,我们在RabbitMQ控制台使用rabbitmqctl list_bindings命令查看绑定关系。

扇形交换机绑定关系

关键部分我用红框标记了起来,这就代表着名叫fanoutExchange的交换机绑定着两个队列,一个叫fanout1,另一个叫fanout2

紧接着,我们来看控制台的打印情况:

扇形交换机确认消息

可以看到,一条信息发送出去之后,两个队列都接收到了这条消息,紧接着由我们的两个消费者消费。

Tip: 如果你的演示应用启动之后没有消费信息,可以尝试重新运行一次生产者的方法发送消息。

3. 📗Direct-Exchange

Direct-Exchange是一种精准匹配的交换机,我们之前一直使用默认的交换机,其实默认的交换机就是Direct类型。

如果将Direct交换机都比作一所公寓的管理员,那么队列就是里面的住户。(绑定关系)

管理员每天都会收到各种各样的信件(消息),这些信件的地址不光要标明地址(ExchangeKey)还需要标明要送往哪一户(routingKey),不然消息无法投递。

扇形交换机

以上图为例,准备一条消息发往名为SendService的直接交换机中去,这个交换机主要是用来做发送服务,所以其绑定了两个队列,SMS队列和MAIL队列,用于发送短信和邮件。

我们的消息除了指定ExchangeKey还需要指定routingKeyroutingKey对应着最终要发送的是哪个队列,我们的示例中的routingKey是sms,这里这条消息就会交给SMS队列。


听了上面这段,可能大家对routingKey还不是很理解,我们上段代码实践一下,大家应该就明白了。

准备工作:

    @Bean
    public Queue directQueue1() {
        return new Queue("directQueue1");
    }

    @Bean
    public Queue directQueue2() {
        return new Queue("directQueue2");
    }

    @Bean
    public DirectExchange directExchange() {
        // 三个构造参数:name durable autoDelete
        return new DirectExchange("directExchange", false, false);
    }

    @Bean
    public Binding directBinding1() {
        return BindingBuilder.bind(directQueue1()).to(directExchange()).with("sms");
    }

    @Bean
    public Binding directBinding2() {
        return BindingBuilder.bind(directQueue2()).to(directExchange()).with("mail");
    }

新建两个队列,新建了一个直接交换机,并设置了绑定关系。

这里的示例代码和上面扇形交换机的代码很像,唯一可以说不同的就是绑定的时候多调用了一个withroutingKey设置了上去。

所以是交换机和队列建立绑定关系的时候设置的routingKey,一个消息到达交换机之后,交换机通过消息上带来的routingKey找到自己与队列建立绑定关系时设置的routingKey,然后将消息分发到这个队列去。

生产者:

    public void sendDirect() {
        Client client = new Client();

        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("directExchange","sms",client);
        System.out.println("消息发送完毕。");
    }

消费者:

@Slf4j
@Component("rabbitDirectConsumer")
public class RabbitDirectConsumer {
    @RabbitListener(queues = "directQueue1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "directQueue2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

效果图如下:

扇形交换机

只有一个消费者进行了消息,符合我们的预期。

4. 📙Topic-Exchange

Topic-Exchange是直接交换机的模糊匹配版本,Topic类型的交换器,支持使用"*"和"#"通配符定义模糊bindingKey,然后按照routingKey进行模糊匹配队列进行分发。

  • *:能够模糊匹配一个单词。
  • #:能够模糊匹配零个或多个单词。

因为加入了两个通配定义符,所以Topic交换机的routingKey也有些变化,routingKey可以使用.将单词分开。


这里我们直接来用一个例子说明会更加的清晰:

准备工作:

    // 主题交换机示例
    @Bean
    public Queue topicQueue1() {
        return new Queue("topicQueue1");
    }

    @Bean
    public Queue topicQueue2() {
        return new Queue("topicQueue2");
    }

    @Bean
    public TopicExchange topicExchange() {
        // 三个构造参数:name durable autoDelete
        return new TopicExchange("topicExchange", false, false);
    }

    @Bean
    public Binding topicBinding1() {
        return BindingBuilder.bind(topicQueue1()).to(topicExchange()).with("sms.*");
    }

    @Bean
    public Binding topicBinding2() {
        return BindingBuilder.bind(topicQueue2()).to(topicExchange()).with("mail.#");
    }

新建两个队列,新建了一个Topic交换机,并设置了绑定关系。

这里的示例代码我们主要看设置routingKey,这里的routingKey用上了通配符,且中间用.隔开,这就代表topicQueue1消费sms开头的消息,topicQueue2消费mail开头的消息,具体不同往下看。

生产者:

    public void sendTopic() {
        Client client = new Client();

        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("topicExchange","sms.liantong",client);
        System.out.println("消息发送完毕。");
    }

消费者:

@Slf4j
@Component("rabbitTopicConsumer")
public class RabbitTopicConsumer {
    @RabbitListener(queues = "topicQueue1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "topicQueue2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

这里我们的生产者发送的消息routingKeysms.liantong,它就会被发到topicQueue1队列中去,这里消息的routingKey也需要用.隔离开,用其他符号无法正确识别。

如果我们的routingKeysms.123.liantong,那么它将无法找到对应的队列,因为topicQueue1的模糊匹配用的通配符是*而不是#,只有#是可以匹配多个单词的。

Topic-ExchangeDirect-Exchange很相似,我就不再赘述了,通配符*#的区别也很简单,大家可以自己试一下。

后记

周一没更文实在惭愧,去医院抽血了,抽了三管~,吃多少才能补回来~

RabbitMQ已经更新了三篇了,这三篇的内容有些偏基础,下一篇将会更新高级部分内容:包括防止消息丢失,防止消息重复消费等等内容,希望大家持续关注。


最近这段时间压力挺大,优狐令我八月底之前升级到三级,所以各位读者的赞对我很重要,希望大家能够高抬贵手,帮我一哈~

好了,以上就是本期的全部内容,感谢你能看到这里,欢迎对本文点赞收藏与评论,👍你们的每个点赞都是我创作的最大动力。

我是耳朵,一个一直想做知识输出的伪文艺程序员,我们下期见。

本文代码:码云地址GitHub地址

查看原文

konohanaruto 赞了文章 · 8月27日

上手了RabbitMQ?再来看看它的交换机(Exchange)吧

人生终将是场单人旅途,孤独之前是迷茫,孤独过后是成长。

楔子

本篇是消息队列RabbitMQ的第三弹。

RabbitMQ的入门RabbitMQ+SpringBoot的整合可以点此链接进去回顾,今天要讲的是RabbitMQ的交换机。

本篇是理解RabbitMQ很重要的一篇,交换机是消息的第一站,只有理解了交换机的分发模式,我们才能知道不同交换机根据什么规则分发消息,才能明白在面对不同业务需求的时候应采用哪种交换机。


祝有好收获,先赞后看,快乐无限。

本文代码:码云地址GitHub地址

1. 🔍Exchange

rabbit架构图

先来放上几乎每篇都要出现一遍的我画了好久的RabbitMQ架构图。

前两篇文中我们一直没有显式的去使用Exchange,都是使用的默认Exchange,其实Exchange是一个非常关键的组件,有了它才有了各种消息分发模式。

我先简单说说Exchange有哪几种类型:

  1. fanoutFanout-Exchange会将它接收到的消息发往所有与他绑定的Queue中。
  2. directDirect-Exchange会把它接收到的消息发往与它有绑定关系且Routingkey完全匹配的Queue中(默认)。
  3. topicTopic-Exchange与Direct-Exchange相似,不过Topic-Exchange不需要全匹配,可以部分匹配,它约定:Routingkey为一个句点号“. ”分隔的字符串(我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词)。
  4. headerHeader-Exchange不依赖于RoutingKey或绑定关系来分发消息,而是根据发送的消息内容中的headers属性进行匹配。此模式已经不再使用,本文中也不会去讲,大家知道即可。

本文中我们主要讲前三种Exchange方式,相信凭借着我简练的文字和灵魂的画技给大家好好讲讲,争取老妪能解。

Tip:本文的代码演示直接使用SpringBoot+RabbitMQ的模式。

2. 📕Fanout-Exchange

先来看看Fanout-ExchangeFanout-Exchange又称扇形交换机,这个交换机应该是最容易理解的。

扇形交换机

ExchangeQueue建立一个绑定关系,Exchange会分发给所有和它有绑定关系的Queue中,绑定了十个Queue就把消息复制十份进行分发。

这种绑定关系为了效率肯定都会维护一张表,从算法效率上来说一般是O(1),所以Fanout-Exchange是这几个交换机中查找需要被分发队列最快的交换机。


下面是一段代码演示:

    @Bean
    public Queue fanout1() {
        return new Queue("fanout1");
    }

    @Bean
    public Queue fanout2() {
        return new Queue("fanout2");
    }

    @Bean
    public FanoutExchange fanoutExchange() {
        // 三个构造参数:name durable autoDelete
        return new FanoutExchange("fanoutExchange", false, false);
    }

    @Bean
    public Binding binding1() {
        return BindingBuilder.bind(fanout1()).to(fanoutExchange());
    }

    @Bean
    public Binding binding2() {
        return BindingBuilder.bind(fanout2()).to(fanoutExchange());
    }

为了清晰明了,我新建了两个演示用的队列,然后建了一个FanoutExchange,最后给他们都设置上绑定关系,这样一组队列和交换机的绑定设置就算完成了。

紧接着编写一下生产者和消费者:

    public void sendFanout() {
        Client client = new Client();

        // 应读者要求,以后代码打印的地方都会改成log方式,这是一种良好的编程习惯,用System.out.println一般是不推荐的。
        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("fanoutExchange",null,client);
        System.out.println("消息发送完毕。");
    }

    @Test
    public void sendFanoutMessage() {
        rabbitProduce.sendFanout();
    }
@Slf4j
@Component("rabbitFanoutConsumer")
public class RabbitFanoutConsumer {
    @RabbitListener(queues = "fanout1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "fanout2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

这两段代码都很好理解,不再赘述,有遗忘的可以去看RabbitMQ第一弹的内容。

其中发送消息的代码有三个参数,第一个参数是Exchange的名称,第二个参数是routingKey的名称,这个参数在扇形交换机里面用不到,在其他两个交换机类型里面会用到。

代码的准备到此结束,我们可以运行发送方法之后run一下了~

项目启动后,我们可以先来观察一下队列与交换机的绑定关系有没有生效,我们在RabbitMQ控制台使用rabbitmqctl list_bindings命令查看绑定关系。

扇形交换机绑定关系

关键部分我用红框标记了起来,这就代表着名叫fanoutExchange的交换机绑定着两个队列,一个叫fanout1,另一个叫fanout2

紧接着,我们来看控制台的打印情况:

扇形交换机确认消息

可以看到,一条信息发送出去之后,两个队列都接收到了这条消息,紧接着由我们的两个消费者消费。

Tip: 如果你的演示应用启动之后没有消费信息,可以尝试重新运行一次生产者的方法发送消息。

3. 📗Direct-Exchange

Direct-Exchange是一种精准匹配的交换机,我们之前一直使用默认的交换机,其实默认的交换机就是Direct类型。

如果将Direct交换机都比作一所公寓的管理员,那么队列就是里面的住户。(绑定关系)

管理员每天都会收到各种各样的信件(消息),这些信件的地址不光要标明地址(ExchangeKey)还需要标明要送往哪一户(routingKey),不然消息无法投递。

扇形交换机

以上图为例,准备一条消息发往名为SendService的直接交换机中去,这个交换机主要是用来做发送服务,所以其绑定了两个队列,SMS队列和MAIL队列,用于发送短信和邮件。

我们的消息除了指定ExchangeKey还需要指定routingKeyroutingKey对应着最终要发送的是哪个队列,我们的示例中的routingKey是sms,这里这条消息就会交给SMS队列。


听了上面这段,可能大家对routingKey还不是很理解,我们上段代码实践一下,大家应该就明白了。

准备工作:

    @Bean
    public Queue directQueue1() {
        return new Queue("directQueue1");
    }

    @Bean
    public Queue directQueue2() {
        return new Queue("directQueue2");
    }

    @Bean
    public DirectExchange directExchange() {
        // 三个构造参数:name durable autoDelete
        return new DirectExchange("directExchange", false, false);
    }

    @Bean
    public Binding directBinding1() {
        return BindingBuilder.bind(directQueue1()).to(directExchange()).with("sms");
    }

    @Bean
    public Binding directBinding2() {
        return BindingBuilder.bind(directQueue2()).to(directExchange()).with("mail");
    }

新建两个队列,新建了一个直接交换机,并设置了绑定关系。

这里的示例代码和上面扇形交换机的代码很像,唯一可以说不同的就是绑定的时候多调用了一个withroutingKey设置了上去。

所以是交换机和队列建立绑定关系的时候设置的routingKey,一个消息到达交换机之后,交换机通过消息上带来的routingKey找到自己与队列建立绑定关系时设置的routingKey,然后将消息分发到这个队列去。

生产者:

    public void sendDirect() {
        Client client = new Client();

        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("directExchange","sms",client);
        System.out.println("消息发送完毕。");
    }

消费者:

@Slf4j
@Component("rabbitDirectConsumer")
public class RabbitDirectConsumer {
    @RabbitListener(queues = "directQueue1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "directQueue2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

效果图如下:

扇形交换机

只有一个消费者进行了消息,符合我们的预期。

4. 📙Topic-Exchange

Topic-Exchange是直接交换机的模糊匹配版本,Topic类型的交换器,支持使用"*"和"#"通配符定义模糊bindingKey,然后按照routingKey进行模糊匹配队列进行分发。

  • *:能够模糊匹配一个单词。
  • #:能够模糊匹配零个或多个单词。

因为加入了两个通配定义符,所以Topic交换机的routingKey也有些变化,routingKey可以使用.将单词分开。


这里我们直接来用一个例子说明会更加的清晰:

准备工作:

    // 主题交换机示例
    @Bean
    public Queue topicQueue1() {
        return new Queue("topicQueue1");
    }

    @Bean
    public Queue topicQueue2() {
        return new Queue("topicQueue2");
    }

    @Bean
    public TopicExchange topicExchange() {
        // 三个构造参数:name durable autoDelete
        return new TopicExchange("topicExchange", false, false);
    }

    @Bean
    public Binding topicBinding1() {
        return BindingBuilder.bind(topicQueue1()).to(topicExchange()).with("sms.*");
    }

    @Bean
    public Binding topicBinding2() {
        return BindingBuilder.bind(topicQueue2()).to(topicExchange()).with("mail.#");
    }

新建两个队列,新建了一个Topic交换机,并设置了绑定关系。

这里的示例代码我们主要看设置routingKey,这里的routingKey用上了通配符,且中间用.隔开,这就代表topicQueue1消费sms开头的消息,topicQueue2消费mail开头的消息,具体不同往下看。

生产者:

    public void sendTopic() {
        Client client = new Client();

        log.info("Message content : " + client);

        rabbitTemplate.convertAndSend("topicExchange","sms.liantong",client);
        System.out.println("消息发送完毕。");
    }

消费者:

@Slf4j
@Component("rabbitTopicConsumer")
public class RabbitTopicConsumer {
    @RabbitListener(queues = "topicQueue1")
    public void onMessage1(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

    @RabbitListener(queues = "topicQueue2")
    public void onMessage2(Message message, Channel channel) throws Exception {
        log.info("Message content : " + message);
        channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        log.info("消息已确认");
    }

}

这里我们的生产者发送的消息routingKeysms.liantong,它就会被发到topicQueue1队列中去,这里消息的routingKey也需要用.隔离开,用其他符号无法正确识别。

如果我们的routingKeysms.123.liantong,那么它将无法找到对应的队列,因为topicQueue1的模糊匹配用的通配符是*而不是#,只有#是可以匹配多个单词的。

Topic-ExchangeDirect-Exchange很相似,我就不再赘述了,通配符*#的区别也很简单,大家可以自己试一下。

后记

周一没更文实在惭愧,去医院抽血了,抽了三管~,吃多少才能补回来~

RabbitMQ已经更新了三篇了,这三篇的内容有些偏基础,下一篇将会更新高级部分内容:包括防止消息丢失,防止消息重复消费等等内容,希望大家持续关注。


最近这段时间压力挺大,优狐令我八月底之前升级到三级,所以各位读者的赞对我很重要,希望大家能够高抬贵手,帮我一哈~

好了,以上就是本期的全部内容,感谢你能看到这里,欢迎对本文点赞收藏与评论,👍你们的每个点赞都是我创作的最大动力。

我是耳朵,一个一直想做知识输出的伪文艺程序员,我们下期见。

本文代码:码云地址GitHub地址

查看原文

赞 18 收藏 11 评论 0

konohanaruto 收藏了文章 · 8月27日

脏读、幻读和不可重复读

一、引言

脏读、不可重复读和幻读是数据库中由于并发访问导致的数据读取问题。当多个事务同时进行时可以通过修改数据库事务的隔离级别来处理这三个问题。

二、问题解释

1、脏读(读取未提交的数据)

脏读又称无效数据的读出,是指在数据库访问中,事务 A 对一个值做修改,事务 B 读取这个值,但是由于某种原因事务 A 回滚撤销了对这个值得修改,这就导致事务 B 读取到的值是无效数据。

2、不可重复读(前后数据多次读取,结果集内容不一致)

不可重复读即当事务 A 按照查询条件得到了一个结果集,这时事务 B 对事务 A 查询的结果集数据做了修改操作,之后事务 A 为了数据校验继续按照之前的查询条件得到的结果集与前一次查询不同,导致不可重复读取原始数据。

3、幻读(前后数据多次读取,结果集数量不一致)

幻读是指当事务 A 按照查询条件得到了一个结果集,这时事务 B 对事务 A 查询的结果集数据做新增操作,之后事务 A 继续按照之前的查询条件得到的结果集平白无故多了几条数据,好像出现了幻觉一样。

三、事务隔离

在并发条件下会出现上述问题,如何着手解决他们保证我们程序运行的正确性是非常重要的。数据库提供了 Read uncommitted 、Read committed 、Repeatable read 、Serializable 四种事务隔离级别来解决脏读、幻读和不可重复读问题,同时容易想到,可以通过加锁的方式实现事务隔离。

在数据库的增删改查操作中,insert 、delete 、update 都会加排他锁,排它锁会阻止其他事务对其加锁的数据加任何类型的锁。而 select 只有显示声明才会加锁。

  • Read uncommitted

    读未提交,说的是一个事务可以读取到另一个事务未提交的数据修改。

    读若不显式声明是不加锁的,可以直接读取到另一个事务对数据的操作,没有避免脏读、不可重复读、幻读。

  • Read committed

    读已提交,说的是一个事务只能读取到另一个事务已经提交的数据修改。

    很明显,这种隔离级别避免了脏读,但是可能会出现不可重复读、幻读。

  • Repeatable read

    可重复读,保证了同一事务下多次读取相同的数据返回的结果集是一样的。

    这种隔离级别解决了脏读和不可重复读问题,但是扔有可能出现幻读。

  • Serializable

    串行化,对同一数据的读写全加锁,即对同一数据的读写全是互斥了,数据可靠行很强,但是并发性能不忍直视。

    这种隔离级别虽然解决了上述三个问题,但是牺牲了性能。

总结如下表: √ 代表可能出现,× 代表不会出现。

隔离级别脏读不可重复读幻读
Read uncommitted
Read committed×
Repeatable read××
Serializable×××

四、MySQL 事务隔离级别的实现

在 MySQL 中只有 InnoDB 存储引擎支持事务,但是在日常使用 MySQL 时我们好像没有怎么关心过上述三个问题啊...

原因很简单,MySQL 默认 Repeatable read 隔离级别,使用了 MVCC 技术,并且解决了幻读问题。

MVCC


MVCC 全名多版本并发控制,使用它可以保证 InnoDB 存储引擎下读操作的一致性。使用 MVCC 可以查询被另一个事务修改的行数据,并且可以查看这些行被更新之前的数据,值得注意的是使用 MVCC 增加了多事务的并发性能,但是并没有解决幻读问题

1、原理

MVCC 是通过保存数据在某个时间点的快照来实现的。也就是说在同一个事务的生命周期中,数据的快照始终是相同的;而在多个事务中,由于事务的时间点很可能不相同,数据的快照也不尽相同。

2、实现细节

  • 每行数据都存在一个版本,每次数据更新时都更新该版本。
  • 修改时Copy出当前版本随意修改,各个事务之间互不干扰。
  • 保存时比较版本号,如果成功(commit),则覆盖原记录;失败则放弃copy(rollback)。

通过上面特点我们可以看出,MVCC 其实就是类似乐观锁的一种实现。

3、InnoDB 中 MVCC 实现

在 InnoDB 中为每行增加两个隐藏的字段,分别是该行数据创建时的版本号删除时的版本号,这里的版本号是系统版本号(可以简单理解为事务的 ID),每开始一个新的事务,系统版本号就自动递增,作为事务的 ID 。通常这两个版本号分别叫做创建时间和删除时间。

下面通过具体的例子来帮助理解 InnoDB 中 MVCC 实现,

首先创建一个表:

create table info( 
id int primary key auto_increment, 
name varchar(20));

INSERT
InnoDB 为新插入的每一行保存当前系统版本号作为版本号。现在假设事务的版本号从 1 开始。

第一个事务 ID为1;

start transaction;
insert into info values(NULL,'a');
insert into info values(NULL,'b');
insert into info values(NULL,'c');
commit;

对应在数据中的表如下(后面两列是隐藏列,也就是版本号)

idname创建版本(事务ID)删除版本(事务ID)
1a1undefined
2b1undefined
3c1undefined
SELECT

InnoDB 会根据下面两个条件检查每行记录:

  • 只会查找版本早于当前事务版本的数据行(行的系统版本号小于或等于事务的系统版本号),这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的
  • 行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行,在事务开始之前未被删除

只有 a, b 同时满足的记录,才能返回作为查询结果.


DELETE

InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)作为删除标识.
看下面的具体例子分析:

第二个事务 ID为2;

start transaction;
select * from info;  //(1)
select * from info;  //(2)
commit;
  • 假设1
    假设在执行这个事务 ID 为 2 的过程中,刚执行到 (1) ,这时,有另一个事务 ID 为 3 往这个表里插入了一条数据;

第三个事务ID为3;

start transaction;
insert into info values(NULL,'d');
commit;

这时表中的数据如下:

idname创建版本(事务ID)删除版本(事务ID)
1a1undefined
2b1undefined
3c1undefined
4d3undefined

然后接着执行 事务2 中的 (2) ,由于 id=4 的数据的创建时间(事务 ID 为 3 ),执行当前事务的 ID 为 2 ,而 InnoDB 只会查找事务 ID 小于等于当前事务 ID 的数据行,所以 id=4 的数据行并不会在执行 事务2 中的 (2) 被检索出来,在 *事务2 *中的两条 select 语句检索出来的数据都只会如下表:

idname创建版本(事务ID)删除版本(事务ID)
1a1undefined
2b1undefined
3c1undefined
  • 假设2
    假设在执行这个事务 ID 为 2 的过程中,刚执行到 (1) ,假设事务执行完 事务3 后,接着又执行了 事务4 ;

第四个事务:

start   transaction;  
delete from info where id=1;
commit;

此时数据库中的表数据如下:

idname创建版本(事务ID)删除版本(事务ID)
1a14
2b1undefined
3c1undefined
4d3undefined

接着执行事务 ID 为 2 的 事务(2),根据 SELECT 检索条件可以知道,它会检索创建时间(创建事务的 ID )小于当前事务 ID 的行和删除时间(删除事务的 ID )大于当前事务的行,而 id=4 的行上面已经说过,而 id=1 的行由于删除时间(删除事务的 ID )大于当前事务的 ID ,所以 事务2 的 (2) select * from info 也会把 id=1 的数据检索出来。所以,事务2 中的两条 select 语句检索出来的数据都如下:

idname创建版本(事务ID)删除版本(事务ID)
1a14
2b1undefined
3c1undefined

UPDATE

InnoDB 执行 UPDATE,实际上是新插入了一行记录,并保存其创建时间为当前事务的 ID ,同时保存当前事务 ID 到要 UPDATE 的行的删除时间。

  • 假设3
    假设在执行完 事务2 的 (1) 后又执行,其它用户执行了事务 3和 4,这时,又有一个用户对这张表执行了 UPDATE 操作:

第五个事务:

start  transaction;
update info set name='b' where id=2;
commit;

根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:

idname创建版本(事务ID)删除版本(事务ID)
1a14
2b15
3c1undefined
4d3undefined
2b5undefined

继续执行 事务2 的 (2) ,根据 select 语句的检索条件,得到下表:

idname创建版本(事务ID)删除版本(事务ID)
1a14
2b15
3c1undefined

还是和 事务2 中 (1) select 得到相同的结果。

❀ 总结:

  • SELECT
    读取创建版本号小于或等于当前事务版本号,并且删除版本号为空或大于当前事务版本号的记录。如此可以保证在事务在读取之前记录是存在的。
  • INSERT
    将当前事务的版本号保存至插入行的创建版本号。
  • UPDATE
    新插入一行,并以当前事务的版本号作为新行的创建版本号,同时将原记录行的删除版本号设置为当前事务版本号。
  • DELETE
    将当前事务的版本号保存至行的删除版本号。

例子参考:https://blog.csdn.net/whoamiy...


4、 InnoDB 如何解决幻读问题

在 InnoDB 中分为快照读当前读。快照读读的是数据的快照,也就是数据的历史版本;当前读就是读的最新版本的数据,并且在读的时候加锁,其他事务都不能对当前行做修改。

  • 快照读:简单的 select 操作,属于快照读,不加锁。
    select * from table where ?;
  • 当前读:特殊的读操作,插入、更新、删除操作,属于当前读,需要加锁。
    select * from table where ? lock in share mode;
    select * from table where ? for update;
    insert into table values (…);
    update table set ? where ?;
    delete from table where ?;

对于上面当前读的语句,第一条读取记录加共享锁,其他的全部加排它锁。

也就是说在做数据的修改操作时,都会使用当前读的方式,当前读是通过行锁和间隙锁控制的,此时是加了排他锁的,所有其他的事务都不能动当前的事务,所以避免了出现幻读的可能。

而为了防止幻读,行锁和间隙锁扮演了重要角色,下面简单说一下:

  • 行锁
    字面意思简单理解对数据行加锁,注意 InnoDB 行锁是通过给索引上的索引项加锁来实现的,也就是说只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁!
  • 间隙锁
    间隙锁就是用来为数据行之间的间隙来进行加锁。

举个例子:

select * from info where id > 5;

上面 SQL 中,其中 id 是主键,假设在一个 事务 A 中执行这个查询,第一次查询为一个 结果集 1 。在做第二次查询时,另一个 事务 B 在 info 表进行了插入数据 7 和 10 的操作。在 事务 A 再次执行此查询查询出 结果集 2 的时候,发现多了几条记录,如此便产生了幻读。

  • 结果集1
6,8,9
  • 结果集2
6,7,8,9,10

所以试想为了防止幻读,我们不但要现存的 id > 5 的数据行(6,8,9)上面加锁(行锁),还要在它们的间隙加锁(间隙锁)。

我们以区间来表示要加锁对象:

(5,6]
(6,8]
(8,9]
(9,+∞)

其中区间的右闭即为要加的行锁,而区间的范围即是要加的间隙锁。

五、结语

关于脏读、不可重复读和幻读的理解便记录到这里了,因笔者水平有限,如有错误欢迎指正。

欢迎访问个人博客 获取更多知识分享。
查看原文

konohanaruto 收藏了文章 · 8月27日

RabbitMQ高级之如何保证消息可靠性?

人生终将是场单人旅途,孤独之前是迷茫,孤独过后是成长。

楔子

本篇是消息队列RabbitMQ的第四弹。

RabbitMQ我已经写了三篇了,基础的收发消息和基础的概念我都已经写了,学任何东西都是这样,先基础的上手能用,然后遇到问题再去解决,无法理解就去深入源码,随着时间的积累对这一门技术的理解也会随之提高。

基础操作已经熟练后,相信大家不可避免的会生出向那更高处攀登的心来,今天我就罗列一些RabbitMQ比较高级的用法,有些用得到有些用不上,但是一定要有所了解,因为大部分情况我们都是面向面试学习~

  • 如何保证消息的可靠性?
  • 消息队列如何进行限流?
  • 如何设置延时队列进行延时消费?


祝有好收获,先赞后看,快乐无限。

本文代码:码云地址GitHub地址

1. 📖如何保证消息的可靠性?

rabbit架构图

先来看看我们的万年老图,从图上我们大概可以看出来一个消息会经历四个节点,只有保证这四个节点的可靠性才能保证整个系统的可靠性。

  • 生产者发出后保证到达了MQ。
  • MQ收到消息保证分发到了消息对应的Exchange。
  • Exchange分发消息入队之后保证消息的持久性。
  • 消费者收到消息之后保证消息的正确消费。

经历了这四个保证,我们才能保证消息的可靠性,从而保证消息不会丢失。

2. 🔍生产者发送消息到MQ失败

我们的生产者发送消息之后可能由于网络闪断等各种原因导致我们的消息并没有发送到MQ之中,但是这个时候我们生产端又不知道我们的消息没有发出去,这就会造成消息的丢失。

为了解决这个问题,RabbitMQ引入了事务机制发送方确认机制(publisher confirm),由于事务机制过于耗费性能所以一般不用,这里我着重讲述发送方确认机制

这个机制很好理解,就是消息发送到MQ那端之后,MQ会回一个确认收到的消息给我们


打开此功能需要配置,接下来我来演示一下配置:

spring:
  rabbitmq:
    addresses: 127.0.0.1
    host: 5672
    username: guest
    password: guest
    virtual-host: /
    # 打开消息确认机制
    publisher-confirm-type: correlated

我们只需要在配置里面打开消息确认即可(true是返回客户端,false是自动删除)。

生产者:

    public void sendAndConfirm() {
        User user = new User();

        log.info("Message content : " + user);

        CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
        rabbitTemplate.convertAndSend(Producer.QUEUE_NAME,user,correlationData);
        log.info("消息发送完毕。");

        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback(){
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                log.info("CorrelationData content : " + correlationData);
                log.info("Ack status : " + ack);
                log.info("Cause content : " + cause);
                if(ack){
                    log.info("消息成功发送,订单入库,更改订单状态");
                }else{
                    log.info("消息发送失败:"+correlationData+", 出现异常:"+cause);
                }
            }
        });
    }

生产者代码里我们看到又多了一个参数:CorrelationData,这个参数是用来做消息的唯一标识,同时我们打开消息确认之后需要对rabbitTemplate多设置一个setConfirmCallback,参数是一个匿名类,我们消息确认成功or失败之后的处理就是写在这个匿名类里面。

比如一条订单消息,当消息确认到达MQ确认之后再行入库或者修改订单的节点状态,如果消息没有成功到达MQ可以进行一次记录或者将订单状态修改。

Tip:消息确认失败不只有消息没发过去会触发,消息发过去但是找不到对应的Exchange,也会触发。

3. 📔MQ接收失败或者路由失败

生产者的发送消息处理好了之后,我们就可以来看看MQ端的处理,MQ可能出现两个问题:

  1. 消息找不到对应的Exchange。
  2. 找到了Exchange但是找不到对应的Queue。

这两种情况都可以用RabbitMQ提供的mandatory参数来解决,它会设置消息投递失败的策略,有两种策略:自动删除或返回到客户端。

我们既然要做可靠性,当然是设置为返回到客户端。


配置:

spring:
  rabbitmq:
    addresses: 127.0.0.1
    host: 5672
    username: guest
    password: guest
    virtual-host: /
    # 打开消息确认机制
    publisher-confirm-type: correlated
    # 打开消息返回
    publisher-returns: true
    template:
      mandatory: true

我们只需要在配置里面打开消息返回即可,template.mandatory: true这一步不要少~

生产者:

    public void sendAndReturn() {
        User user = new User();

        log.info("Message content : " + user);

        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            log.info("被退回的消息为:{}", message);
            log.info("replyCode:{}", replyCode);
            log.info("replyText:{}", replyText);
            log.info("exchange:{}", exchange);
            log.info("routingKey:{}", routingKey);
        });

        rabbitTemplate.convertAndSend("fail",user);
        log.info("消息发送完毕。");
    }

这里我们可以拿到被退回消息的所有信息,然后再进行处理,比如放到一个新的队列单独处理,路由失败一般都是配置问题了。

4. 📑消息入队之后MQ宕机

到这一步基本都是一些很小概率的问题了,比如MQ突然宕机了或者被关闭了,这种问题就必须要对消息做持久化,以便MQ重新启动之后消息还能重新恢复过来。

消息的持久化要做,但是不能只做消息的持久化,还要做队列的持久化和Exchange的持久化。

    @Bean
    public DirectExchange directExchange() {
        // 三个构造参数:name durable autoDelete
        return new DirectExchange("directExchange", false, false);
    }

    @Bean
    public Queue erduo() {
        // 其三个参数:durable exclusive autoDelete
        // 一般只设置一下持久化即可
        return new Queue("erduo",true);
    }

创建Exchange和队列时只要设置好持久化,发送的消息默认就是持久化消息。

设置持久化时一定要将Exchange和队列都设置上持久化:

单单只设置Exchange持久化,重启之后队列会丢失。单单只设置队列的持久化,重启之后Exchange会消失,既而消息也丢失,所以如果不两个一块设置持久化将毫无意义。

Tip: 这些都是MQ宕机引起的问题,如果出现服务器宕机或者磁盘损坏则上面的手段统统无效,必须引入镜像队列,做异地多活来抵御这种不可抗因素。

5. 📌消费者无法正常消费

最后一步会出问题的地方就在消费者端了,不过这个解决问题的方法我们之前的文章已经说过了,就是消费者的消息确认。

spring:
  rabbitmq:
    addresses: 127.0.0.1
    host: 5672
    username: guest
    password: guest
    virtual-host: /
    # 手动确认消息
    listener:
      simple:
          acknowledge-mode: manual

打开手动消息确认之后,只要我们这条消息没有成功消费,无论中间是出现消费者宕机还是代码异常,只要连接断开之后这条信息还没有被消费那么这条消息就会被重新放入队列再次被消费。

当然这也可能会出现重复消费的情况,不过在分布式系统中幂等性是一定要做的,所以一般重复消费都会被接口的幂等给拦掉。

所谓幂等性就是:一个操作多次执行产生的结果与一次执行产生的结果一致。

幂等性相关内容不在本章讨论范围~所以我就不多做阐述了。

6. 💡消息可靠性案例

消息可靠性架构

这个图是我很早之前画的,是为了记录当时使用RabbitMQ做消息可靠性的具体做法,这里我正好拿出来做个例子给大家看一看。

这个例子中的消息是先入库的,然后生产者从DB里面拿到数据包装成消息发给MQ,经过消费者消费之后对DB数据的状态进行更改,然后重新入库。

这中间有任何步骤失败,数据的状态都是没有更新的,这时通过一个定时任务不停的去刷库,找到有问题的数据将它重新扔到生产者那里进行重新投递。

这个方案其实和网上的很多方案大同小异,基础的可靠性保证之后,定时任务做一个兜底进行不断的扫描,力图100%可靠性。

后记

越写越长,因为篇幅缘故限流和延时队列放到下一篇了,我会尽快发出来供大家阅读,讲真,我真的不是故意多水一篇的!!!

最后再给优狐打个广告,最近掘金在GitHub上面建立了一个开源计划 - open-source,旨在收录各种好玩的好用的开源库,如果大家有想要自荐或者分享的开源库都可以参与进去,为这个开源计划做一份贡献,同时这个开源库的Start也在稳步增长中,参与进去也可以增加自己项目的曝光度,一举两得。

同时这个开源库还有一个兄弟项目 - open-source-translation,旨在招募技术文章翻译志愿者进行技术文章的翻译工作,
争做最棒开源翻译,翻译业界高质量文稿,为技术人的成长献一份力。


最近这段时间事情挺多,优狐令我八月底之前升级到三级,所以各位读者的赞对我很重要,希望大家能够高抬贵手,帮我一哈~

好了,以上就是本期的全部内容,感谢你能看到这里,欢迎对本文点赞收藏与评论,👍你们的每个点赞都是我创作的最大动力。

我是耳朵,一个一直想做知识输出的伪文艺程序员,我们下期见。

本文代码:码云地址GitHub地址

查看原文

konohanaruto 回答了问题 · 7月9日

解决爬取头条文章详情页时cookie中的__ac_nonce是什么?

问题自己已经找到了答案,我发现用postman每次请求,响应头中的__ac_nonce都附有新的值,但body的响应速度不稳定,有时候非常慢。

解决方案是:不要响应body内容,仅要求得到响应头信息,这样就不会导致body超时而无法正确设置__ac_nonce值,php代码:

curl_setopt($ch, CURLOPT_NOBODY, true); // 最核心的一行代码解决问题,拒绝body返回

每次都会得到响应的__ac_nonce值:

HTTP/2 200
server: Tengine
content-type: text/html
content-length: 682
date: Thu, 09 Jul 2020 12:58:31 GMT
vary: Accept-Encoding
set-cookie: __ac_nonce=05f07147700e7b19045f9; Path=/; Max-Age=1800
server-timing: inner; dur=4
x-tt-trace-host: 0183a88c5cb521b4b793d71cf69322c4d084c3d1b6113acf546d6ca2abcd1ffb2c74c68419495975cdb2f8d8caa8132033892b1d35699d42ecd925fe0c7a278105f02a151ccfda62976bffffade8bbdce3
x-tt-trace-tag: id=3;cdn-cache=miss
server-timing: cdn-cache;desc=MISS,edge;dur=0,origin;dur=48
via: vcache49.cn2658[48,0]
timing-allow-origin: *
eagleid: b73d7cc515942995115473548e

"

关注 1 回答 1

konohanaruto 提出了问题 · 7月9日

解决爬取头条文章详情页时cookie中的__ac_nonce是什么?

今天尝试了一下用php拉取头条文章内容,但并不是那么顺利,整体分成三个步骤。

首先,如果我们直接请求文章内容,以postman举例,它会返回如下一段Javascript代码:

image.png

<html><head><meta charset="UTF-8" /></head><body></body><script data-original='https://sf1-ttcdn-tos.pstatp.com/obj/rc-web-sdk/acrawler.js'></script><script>window.byted_acrawler.init({aid:99999999,dfp:!0});var b;a:{for(var c=document.cookie.split(/[;&]/),d,e=0;e<c.length;e++){for(d=c[e];" "===d.charAt(0);)d=d.substring(1,d.length);if(0===d.indexOf("__ac_nonce=")){b=d.substring(11,d.length);break a}}b=""}var f=b;var g=window.byted_acrawler.sign("",f);document.cookie="__ac_signature=; expires=Mon, 20 Sep 1970 00:00:00 UTC; path=/;";
document.cookie="__ac_signature="+g+"; expires="+(new Date((new Date).getTime()+18E5)).toGMTString()+"; path=/;";window.location.reload();</script></html>

分析下上面这段代码就知道,它从cookie中获取__ac_nonce这个值,然后用acrawler.js文件中的方法加密成一串__ac_signature,这些都可以理解,没有问题。

有个疑问:__ac_nonce是怎么来的??

继续看刚才用post请求的响应信息,我发现这个值是通过头条响应头带过来的。

image.png

尝试不断请求,是否每次头条都会响应__ac_nonce值,于是我尝试写了如下一个demo脚本:

$ch = curl_init();
$headers = [
    'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36',
];

curl_setopt($ch, CURLOPT_URL, 'https://www.toutiao.com/a6846918379043815950');
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 3);

$rs = curl_exec($ch);
// 查看具体返回值
var_dump($rs, curl_error($ch));
// 响应头中匹配cookie部分,为了获取__ac_nonce值
preg_match_all('/^Set-Cookie:\s*([^;]*)/mi', $rs, $matches);
$cookies = [];
$nonce = "";
foreach($matches[1] as $item) {
    parse_str($item, $cookie);
    $cookies = array_merge($cookies, $cookie);
}
if (! empty($cookies['__ac_nonce'])) {
    $nonce = $cookies['__ac_nonce'];
}

echo 'ac_nonce: ' . $nonce . PHP_EOL;

很遗憾,结果极度不稳定:

bool(false)
string(67) "Operation timed out after 2540 milliseconds with 682 bytes received"

但还是有部分请求给我重新分配了__ac_nonce值,只是没有的情况比较多,这是什么问题?

附言

拿到__ac_nonce配合nodejs生成__ac_signature我最后在拉取详情的时候把请求头带上cookie成功的拉到了头条内容, 如下:

// ...
$headers = [
    'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36',
    'cookie: __ac_nonce=xxx;__ac_signature=xxx;',
];
// ...

所以,问题是:什么是__ac_nonce?怎么100%稳定得到它的值?

关注 1 回答 1

konohanaruto 提出了问题 · 7月7日

微信无法在关闭页面事件中发送网络请求上报数据?

由于需要用户在关闭微信内h5页面的时候记录一些数据,所以现在前端需要在关闭事件中请求后端接口上报数据。

现在使用的是pagehide事件去监听页面关闭,可以正常捕获到关闭事件。但是,在微信内打开的h5页面无法成功的发出网络请求(电脑端可以),后台无法收到请求

伪代码如下:

// ...
window.addEventListener('pagehide', () => {  
  const xhr = new XMLHttpRequest()  
  xhr.onreadystatechange = () => {  
    if (xhr.readyState === 4 && xhr.status === 200) {  
      //  
    }  
  }   
  xhr.open('post', 'https://xxxx/h5/report', false)  
  xhr.send(JSON.stringify({ 
    action: 4,  
    dataID: 1
    // 其它...
  }))  
})
// ...

有没有哪位同学遇到和我同样的需求的,希望能指点一二,感谢!

关注 2 回答 2

konohanaruto 收藏了文章 · 2019-12-07

PHP进阶学习之垃圾回收机制详解

一、概念

垃圾回收机制是一种动态存储分配的方案。它会自动释放程序不再需要的已分配的内存块。垃圾回收机制可以让程序员不必过分关心程序内存分配,从而将更多的精力投入到业务逻辑。

在现在的流行各种语言当中,垃圾回收机制是新一代语言所共有的特征,如Python、PHP、C#、Ruby等都使用了垃圾回收机制。

二、PHP垃圾回收机制

1、在PHP5.3版本之前,使用的垃圾回收机制是单纯的“引用计数”。即:
①每个内存对象都分配一个计数器,当内存对象被变量引用时,计数器+1;
②当变量引用撤掉后(执行unset()后),计数器-1;
③当计数器=0时,表明内存对象没有被使用,该内存对象则进行销毁,垃圾回收完成。

并且PHP在一个生命周期结束后就会释放此进程/线程所占的内容,这种方式决定了PHP在前期不需要过多考虑内存的泄露问题。

但是当两个或多个对象互相引用形成环状后,内存对象的计数器则不会消减为0;这时候,这一组内存对象已经没用了,但是不能回收,从而导致内存泄露的现象。

php5.3开始,使用了新的垃圾回收机制,在引用计数基础上,实现了一种复杂的算法,来检测内存对象中引用环的存在,以避免内存泄露。

2、随着PHP的发展,PHP开发者的增加以及其所承载的业务范围的扩大,在PHP5.3中引入了更加完善的垃圾回收机制,新的垃圾回收机制解决了无法处理循环的引用内存泄漏问题。

如官方文档所说:每个php变量存在一个叫"zval"的变量容器中。一个zval变量容器,除了包含变量的类型和值,还包括两个字节的额外信息。第一个是"is_ref",是个bool值,用来标识这个变量是否是属于引用集合(reference set)。通过这个字节,php引擎才能把普通变量和引用变量区分开来,由于php允许用户通过使用&来使用自定义引用,zval变量容器中还有一个内部引用计数机制,来优化内存使用。

第二个额外字节是"refcount",用以表示指向这个zval变量容器的变量(也称符号即symbol)个数。所有的符号存在一个符号表中,其中每个符号都有作用域(scope)。简单的理解如下图所示:
image

官方文档所说,可以使用Xdebug来检查引用计数情况:

<?php
$a = "new string";
$c = $b = $a;
xdebug_debug_zval( 'a' );
unset( $b, $c );
xdebug_debug_zval( 'a' );
?>

以上例程会输出:

a: (refcount=3, is_ref=0)='new string'
a: (refcount=1, is_ref=0)='new string'

注意:从PHP7的NTS版本开始,以上例程的引用将不再被计数,即$c=$b=$a之后a的引用计数也是1.具体分类如下:
在PHP 7中,zval可以被引用计数或不被引用。在zval结构中有一个标志确定了这一点。
①对于null,bool,int和double的类型变量,refcount永远不会计数;

②对于对象、资源类型,refcount计数和php5的一致;

③对于字符串,未被引用的变量被称为“实际字符串”。而那些被引用的字符串被重复删除(即只有一个带有特定内容的被插入的字符串)并保证在请求的整个持续时间内存在,所以不需要为它们使用引用计数;如果使用了opcache,这些字符串将存在于共享内存中,在这种情况下,您不能使用引用计数(因为我们的引用计数机制是非原子的);

④对于数组,未引用的变量被称为“不可变数组”。其数组本身计数与php5一致,但是数组里面的每个键值对的计数,则按前面三条的规则(即如果是字符串也不在计数);如果使用opcache,则代码中的常量数组文字将被转换为不可变数组。

再次,这些生活在共享内存,因此不能使用refcounting。

我们的demo例子如下:

<?php
echo '测试字符串引用计数';
$a = "new string";
$b = $a;
xdebug_debug_zval( 'a' );
unset( $b);
xdebug_debug_zval( 'a' );
$b = &$a;
xdebug_debug_zval( 'a' );
echo '测试数组引用计数';
$c = array('a','b');
xdebug_debug_zval( 'c' );
$d = $c;
xdebug_debug_zval( 'c' );
$c[2]='c';
xdebug_debug_zval( 'c' );
echo '测试int型计数';
$e = 1;
xdebug_debug_zval( 'e' );

看到的输出如下:
image
三、回收周期

默认的,PHP的垃圾回收机制是打开的,然后有个php.ini设置允许你修改它:zend.enable_gc 。

当垃圾回收机制打开时,算法会判断每当根缓存区存满时,就会执行循环查找。根缓存区有固定的大小,默认10,000,可以通过修改PHP源码文件Zend/zend_gc.c中的常量GC_ROOT_BUFFER_MAX_ENTRIES,然后重新编译PHP,来修改这个值。当垃圾回收机制关闭时,循环查找算法永不执行,然而,根将一直存在根缓冲区中,不管在配置中垃圾回收机制是否激活。

除了修改配置zend.enable_gc ,也能通过分别调用gc_enable() 和 gc_disable()函数在运行php时来打开和关闭垃圾回收机制。调用这些函数,与修改配置项来打开或关闭垃圾回收机制的效果是一样的。即使在可能根缓冲区还没满时,也能强制执行周期回收。你能调用gc_collect_cycles()函数达到这个目的。这个函数将返回使用这个算法回收的周期数。

允许打开和关闭垃圾回收机制并且允许自主的初始化的原因,是由于你的应用程序的某部分可能是高时效性的。在这种情况下,你可能不想使用垃圾回收机制。当然,对你的应用程序的某部分关闭垃圾回收机制,是在冒着可能内存泄漏的风险,因为一些可能根也许存不进有限的根缓冲区。

因此,就在你调用gc_disable()函数释放内存之前,先调用gc_collect_cycles()函数可能比较明智。因为这将清除已存放在根缓冲区中的所有可能根,然后在垃圾回收机制被关闭时,可留下空缓冲区以有更多空间存储可能根。

四、性能影响

1、内存占用空间的节省

首先,实现垃圾回收机制的整个原因是为了一旦先决条件满足,通过清理循环引用的变量来节省内存占用。在PHP执行中,一旦根缓冲区满了或者调用gc_collect_cycles() 函数时,就会执行垃圾回收。

2、执行时间增加

垃圾回收影响性能的第二个领域是它释放已泄漏的内存耗费的时间。
通常,PHP中的垃圾回收机制,仅仅在循环回收算法确实运行时会有时间消耗上的增加。但是在平常的(更小的)脚本中应根本就没有性能影响。

3、在平常脚本中有循环回收机制运行的情况下,内存的节省将允许更多这种脚本同时运行在你的服务器上。因为总共使用的内存没达到上限。

这种好处在长时间运行脚本中尤其明显,诸如长时间的测试套件或者daemon脚本此类。同时,对通常比Web脚本运行时间长的脚本应用程序,新的垃圾回收机制,应该会大大改变一直以来认为内存泄漏问题难以解决的看法。

很多PHPer在进阶的时候总会遇到一些问题和瓶颈,业务代码写多了没有方向感,不知道该从那里入手去提升,对此我整理了一些资料,包括但不限于:分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6,laravel,YII2,Redis,Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家,需要请戳这里
查看原文

认证与成就

  • 获得 48 次点赞
  • 获得 20 枚徽章 获得 1 枚金徽章, 获得 4 枚银徽章, 获得 15 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2016-09-12
个人主页被 649 人浏览