文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布

你的Outlook真的安全？一条恶意规则远程攻陷你的工作站！

在此我们也看到了不同的思路，这里我们也强烈建议大家去阅读他们的研究。 简介 在Outlook中设定一条规则，只要满足相应的条件，就能在接收邮件和发送邮件的时候执行某些操作。...比如说，将来自某些特定联系人的邮件进行分类，或者如果邮件标题包含某个关键词，则对邮件进行标注。另外这里所说的“执行某些操作”也可以是运行某个应用，如果能做到这一点，那么一切都变得相当有趣了。...客户端上进行身份验证，那么该规则将会被重新下载，如果payload在新设备上被访问，那么它也会发挥像在第一台设备上那样的作用，当条件满足时，我们就会得到另一个shell。...通过来自MFCMAPI的代码，将.msg文件导入到相关联的内容表中，也就在Exchange服务器上创建规则了，这应该就算得上首个基本完成的POC了。...这基本已经能够达到目的了，似乎已经充满了希望，但是我在测试中却遇到了关于设置PR_RULE_MSG_ACTIONS属性的问题。该属性的描述文档谈到，这是客户端生成的不透明blob，但它也会被用于验证。

3.8K70

3分钟白话RocketMQ系列—— 如何保证消息顺序性

保证「消息生产」的顺序性，则必须满足以下条件： 单一生产者：消息生产的顺序性仅支持单一生产者，不同生产者分布在不同的系统，即使设置相同的分区键，不同生产者之间产生的消息也无法判定其先后顺序。...满足以上条件的生产者，将 「顺序消息」 发送至服务端后，会保证设置了同一分区键的消息，按照发送顺序存储在同一队列中。...局部有序（分区有序） 注意，在RocketMQ 5.x版本中，新增了「消息组」概念，顺序消息发送必须要设置消息组。 保证「消息消费」的顺序性，则必须满足以下条件： 语义正确。...顺序消息消费投递次数限定有限范围内，即一条消息如果超过最大重试次数后，将跳过这条消息消费，不会一直阻塞后续消息处理。...如果上述任意一个条件不满足，则是保证可用性而不是严格顺序。 Q4: 顺序消息有哪些限制？ 1）同一条消息是否可以既是顺序消息，又是定时消息和事务消息？ 不可以。

3.8K32
    • 您找到你想要的搜索结果了吗？
    是的
    没有找到

    我从可靠性聊到幂等性，从Kafka聊到RocketMQ，他沉默了

    没问题，让它也来订阅消息就行，订单系统代码一行都不用改！ 这就是解耦，它让我们的系统更加健壮、易于扩展。 用户注册时，除了写入用户表，我们可能还要发送欢迎邮件、发放新人优惠券。...如果所有操作都同步完成，用户可能需要等待好几秒才能看到“注册成功”的提示，体验极差。 通过MQ，我们可以把非核心、耗时的操作异步化。...通过这种“削峰填谷”，MQ将瞬时的流量洪峰，变成了平稳的细水长流，从而保护了后端脆弱的数据库。 二、面试进阶：如何保证消息的100%可靠？...Redis分布式锁 (SETNX)：为每一条消息生成一个唯一的ID。...重复的消息执行时，WHERE条件不满足，自然就不会重复更新。 四、秀翻全场：三大主流MQ，我该如何选型？ 这个问题能充分展示你的技术广度和架构权衡能力。记住，没有最好，只有最合适。

    16210

    salesforce零基础学习（八十五）streaming api 简单使用（接近实时获取你需要跟踪的数据的更新消息状态）

    NotifyForOperationCreate：指定此字段值为true情况下，当操作的sObject进行insert操作，并且满足query的查询条件，则server端会推送一条通知给所有的订阅者们，...如果将此字段设置值为37.0及以上，Streaming API支持存储24小时内满足条件的数据通知信息，即使客户端订阅渠道后，也可以重播24小时内的以前的数据。...一条记录有可能出现增删改等很多的事件，每一个广播事件通过replayId作为编号，replayId在org和渠道中是唯一的，即使事件被删除后，此事件对应的replayId也不会被重用，订阅者可以通过赋值...当渠道成功后，PushTopic定义的query的数据执行的操作事件（create/update/delete/undelete）满足了PushTopic定义的操作条件，渠道将会向所有订阅的客户端发送通知...三.代码举例 官方提供了两个demo，一个是基于数据进行DML操作发送给订阅者消息，一个是主动广播发送给订阅者消息。

    2.2K80

    如何搞定Kafka重复消费？

    解决方案 方案一  /  保存并查询 给每个消息都设置一个独一无二的 key，消费的时候把 key 记录下来，然后每次消费新的消息的时候都查询一下，看当前消息的这个 key 是否消费过，如果没有消费过才进行消费...只要提供的参数 100万元不变，那即使再执行多少次，X 老师的账户余额始终都是 100万元，不会变化，这个操作就是一个幂等的操作。...在转账流水表增加一条转账记录这个操作中，由于我们在这个表中预先定义了“账户 ID 转账单 ID”的唯一约束，对于同一个转账单同一个账户只能插入一条记录，后续重复的插入操作都会失败，这样就实现了一个幂等的操作...这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。...设置前置条件.png 最后 今天给大家提供的消息重复的解决方案，也参考了《消息队列高手课》里的思路，大家如果有什么好的解决方案，欢迎讨论！

    1.4K20

    什么？搞不定Kafka重复消费？

    解决方案 方案一 / 保存并查询 给每个消息都设置一个独一无二的 key，消费的时候把 key 记录下来，然后每次消费新的消息的时候都查询一下，看当前消息的这个 key 是否消费过，如果没有消费过才进行消费...只要提供的参数 100万元不变，那即使再执行多少次，X 老师的账户余额始终都是 100万元，不会变化，这个操作就是一个幂等的操作。 再举一个例子?...在转账流水表增加一条转账记录这个操作中，由于我们在这个表中预先定义了“账户 ID 转账单 ID”的唯一约束，对于同一个转账单同一个账户只能插入一条记录，后续重复的插入操作都会失败，这样就实现了一个幂等的操作...这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。...比如，刚刚我们说过，“将 X 老师的账户的余额增加 100 万元”这个操作并不满足幂等性，我们可以把这个操作加上一个前置条件，变为：“如果X老师的账户当前的余额为 500万元，将余额加 100万元”，这个操作就具备了幂等性

    1.4K20

    spring-kafka中ContainerProperties.AckMode详解

    一行代码几十倍，数据听起来很夸张，不过这是真实的数据，线上错误的配置的确有可能导致性能有数量级上的差异，等我说完我们这个性能问题你就清楚了。   ...经过排查发现，单条kafka消息处理需要6ms，拆分所有执行逻辑后发现这6ms的延迟主要是向腾讯云发送ack的时间，我们机房到腾讯云的rtt恰好就是6ms左右，所以几乎所有的事件都耗费在消息的网络传输上面了...后来偶然发现我们在代码中使用了spring-kafka的AckMode中的MANUAL_IMMEDIATE，这个模式下kafka的consumer会向服务端手动确认每一条消息，后来我们将这个配置调整成了...COUNT：每处理设定数量的记录后，确认最后一条处理的记录。COUNT_TIME：组合了TIME和COUNT，即满足任意一个条件时，确认最后一条处理的记录。...TIME_COUNT  针对于TIME和COUNT的优缺点，TIME_COUNT结合了两者的特点，只要是时间间隔或者消息条数满足其一就确认，具有更强的适应性，所以当你想从TIME、COUT、TIME_COUNT

    1.3K20

    一文搞懂kafaka重复消费

    解决方案 方案一 / 保存并查询 给每个消息都设置一个独一无二的 key，消费的时候把 key 记录下来，然后每次消费新的消息的时候都查询一下，看当前消息的这个 key 是否消费过，如果没有消费过才进行消费...只要提供的参数 100万元不变，那即使再执行多少次，X 老师的账户余额始终都是 100万元，不会变化，这个操作就是一个幂等的操作。 再举一个例子?...在转账流水表增加一条转账记录这个操作中，由于我们在这个表中预先定义了“账户 ID 转账单 ID”的唯一约束，对于同一个转账单同一个账户只能插入一条记录，后续重复的插入操作都会失败，这样就实现了一个幂等的操作...这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。...比如，刚刚我们说过，“将 X 老师的账户的余额增加 100 万元”这个操作并不满足幂等性，我们可以把这个操作加上一个前置条件，变为：“如果X老师的账户当前的余额为 500万元，将余额加 100万元”，这个操作就具备了幂等性

    1.1K20

    Go语言中常见100问题-#72 Forgetting about sync.Cond

    无论在什么情况下,发往channel的消息只能被消费一次，也就是上面的每个消息都只有一个goroutine会收到。...官方文档(pkg.go.dev/sync)对sync.Cond的定义如下 ❝Cond实现了一个条件变量或者说是一个集合点，在这个点所有的goroutine等待或告知事件发生。...不会的，Wait的内部实现如下： 释放锁（本文是互斥锁） 挂起当前的goroutine并等待通知 执行加锁当接收到通知后 因此，在监听goroutine的内部形成了两个临界区。...当我们发送一条通知消息的时候，例如一条空消息chan struct，即使没有准备就绪的接收者(goroutine),通知消息也会被缓存，从而保证所有的接收者goroutine会收到通知。...「NOTE:Broadcast操作不会阻塞，即使没有goroutine在等待从该通道中接收消息。同理，Signal()操作也类似的，也不会阻塞。

    1.4K40

    「查缺补漏」巩固你的RocketMQ知识体系

    ，这样即使发生宕机，由于消息已经被写入磁盘，就不会丢失消息，恢复后还可以继续消费。...（2）为更新的数据设置前置条件 给数据变更设置一个前置条件，如果满足条件就更新数据，否则拒绝更新数据，在更新数据的时候，同时变更前置条件中需要判断的数据。...这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。...比如，“将账户 X 的余额增加 100 元”这个操作并不满足幂等性，我们可以把这个操作加上一个前置条件，变为：“如果账户 X 当前的余额为 500 元，将余额加 100 元”，这个操作就具备了幂等性。...这样就基本实现了“要么都成功，要么都失败”的一致性要求。

    55361

    ZooKeeper学习第七期--ZooKeeper一致性原理

    待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。...② 我们必须丢弃已经被skip的消息。 (3) 保证示例 第一条： 若一条消息在一台机器上被deliver，那么该消息必须将在每台机器上deliver，即使那台机器故障了。...这一条是为了保证一致性，因为如果一条消息P已经在旧Leader-Server1中deliver了，即使它刚刚将消息P deliver之后就挂了，但是当旧Leader-Server1重启恢复之后，我们的Client...Server1为Leader，他生成了 三条Proposal，P1、P2、P3。但是在发送完P1之后，Server1就挂了。如下图3.6所示。 图 3.6 Server1为Leader ?...(b) 一些已经Skip的消息，需要仍然被Skip。 我想对于第一条保证大家都能理解，它主要是为了保证每 个Server的数据视图的一致性。我重点解释一下第二条，它是如何实现。

    38310

    深入解读zookeeper一致性原理

    待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。...② 我们必须丢弃已经被skip的消息。 (3) 保证示例 第一条： 若一条消息在一台机器上被deliver，那么该消息必须将在每台机器上deliver，即使那台机器故障了。...这一条是为了保证一致性，因为如果一条消息P已经在旧Leader-Server1中deliver了，即使它刚刚将消息P deliver之后就挂了，但是当旧Leader-Server1重启恢复之后，我们的Client...Server1为Leader，他生成了 三条Proposal，P1、P2、P3。但是在发送完P1之后，Server1就挂了。如下图3.6所示。 图 3.6 Server1为Leader ?...(b) 一些已经Skip的消息，需要仍然被Skip。 我想对于第一条保证大家都能理解，它主要是为了保证每 个Server的数据视图的一致性。我重点解释一下第二条，它是如何实现。

    2.7K30

    requestLayout竟然涉及到这么多知识点

    我把这个问题拆分成了两个问题，本文我将紧紧围绕这两个问题，讲解requestLayout背后的故事。...newSurface) { performDraw(); } } 该方法的作用： 「满足条件的情况下调用performMeasure()」 「满足条件的情况下调用performLayout...()」 「满足条件的情况下调用performDraw()」 mStopped表示Activity是否处于stopped状态。...本文我就不展开讲了。即使对Handler不是很了解，也不影响本层次的学习。 ❝ A同学：同步屏障。感觉好高大上的样子？能给我讲讲吗？ 我：乍一看，是挺高大上的。让人望而生畏。...上图，三种类型消息全部存在，msg1是同步屏障消息。同步屏障消息并不会真正执行，它也不会主动出队列，需要调用MessageQueue的removeSyncBarrier()方法。

    71120

    高性能网络编程5--IO复用与并发编程

    即，等待消息准备好的代码段，与处理消息的代码段是分离的。当然，这也要求套接字必须是非阻塞的，否则，处理消息的代码段很容易导致条件不满足时，所在线程又进入了睡眠等待阶段。...多路复用就是处理等待消息准备好这件事的，但它可以同时处理多个连接！它也可能“等待”，所以它也会导致线程睡眠，然而这不要紧，因为它一对多、它可以监控所有连接。...这样，当我们的线程被唤醒执行时，就一定是有一些连接准备好被我们的代码执行了，这是有效率的！没有那么多个线程都在争抢处理“等待消息准备好”阶段，整个世界终于清净了！...用我在《深入理解Nginx》第8章中所画的图来看，它是非常简单的： ? 图中左下方的红黑树由所有待监控的连接构成。左上方的链表，同是目前所有活跃的连接。...LT是每次满足期待状态的连接，都得在epoll_wait中返回，所以它一视同仁，都在一条水平线上。ET则不然，它倾向更精确的返回连接。

    86110

    工具系列 | Redis Stream 类型的消息队列

    除了服务端自动生成 Id 方式外，也支持指定 Id 的生成，但是指定 Id 有以下条件限制： Id 中的前后部分必须为数字。最小 Id 为 0-1，不能为 0-0，但是 2-0，3-0 .......时间戳是毫秒级单位，是生成消息的 Redis 服务器时间，它是个 64 位整型（int64）。序号是在这个毫秒时间点内的消息序号，它也是个 64 位整型。...由于 ID 中包含时间戳部分，为了避免服务器时间错误而带来的问题（例如服务器时间延后了），Redis 的每个 Stream 类型数据都维护一个 latest_generated_id 属性，用于记录最后一个消息的...19 4) (integer) 5 # 注意，读取次数也累加了1次 以上代码，完成了一次消息转移。...被转移的消息的 IDLE 会被重置，用以保证不会被重复转移，以为可能会出现将过期的消息同时转移给多个消费者的并发操作，设置了 IDLE，则可以避免后面的转移不会成功，因为 IDLE 不满足条件。

    1.7K10

    面试官：消息队列中，消息可靠性、重复消息、消息积压、利用消息实现分布式事务如何实现...

    客户端收到响应后，完成了一次正常消息的发送 只要Producer收到了Broker的确认响应就可以保证消息在生产阶段不会丢失。...如果Broker没有收到消费确认响应，下次拉消息的时候还会返回同一条消息，确认消息不会在网络传输过程中丢失，也不会因为客户端在执行消费逻辑中出错导致丢失 在编写消费代码时需要注意的是，不要在收到消息后就立即发送消费确认...，给数据变更设置一个前置条件，如果满足条件就更新数据，否则拒绝更新数据，在更新数据的时候，同时变更前置条件中需要判断的数据。...这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作 比如，将账户X的余额增加100元这个操作并不满足幂等性，可以把这个操作加上一个前置条件...这样就基本实现了要么都成功，要么都失败的一致性要求 如果在第四步提交事务消息时失败了，Kafka会直接抛出异常，让用户自行处理，可以在业务代码中反复重试提交，直到提交成功，或者删除之前创建的订单进行补偿

    70810

    消息队列之事务消息，RocketMQ 和 Kafka 是如何做的？

    通常我们理解的事务就是为了一些更新操作要么都成功，要么都失败，不会有中间状态的产生，而 ACID 是一个严格的事务实现的定义，不过在单体系统时候一般都不会严格的遵循 ACID 的约束来实现事务，更别说分布式系统了...这里的重点就是 2PC 只适用于数据库层面的事务，什么意思呢？就是你想在数据库里面写一条数据同时又要上传一张图片，这两个操作 2PC 无法保证两个操作满足事务的约束。...如果成功那么就将半消息恢复到正常要发送的队列中，这样消费者就可以消费这条消息了。 我们再来简单的看下如何使用，我根据官网示例代码简化了下。...我大致说一下流程，这一步骤其实涉及到的代码很多，我就不贴代码了，有兴趣的同学自行了解。不过我相信用语言也是能说清楚的。...最后协调者会向事务日志中再记一条事务结束信息，至此 Kafka 事务就完成了，我拿 confluent.io 上的图来总结一下这个流程。

    67020

    使用消息队列如何保证幂等性？

    同一条消息Kafka保证底层日志中只会持久化一次，既不会丢失也不会重复。幂等性可以极大地减轻下游consumer系统实现消息去重的工作负担，因此是非常实用的功能。...，因此PID的生成和分配对用户来说是完全透明的，用户无需考虑PID的事情，甚至都感受不到PID的存在。...Kafka设置acks=all，即需要相应的所有处于ISR的分区都确认收到该消息后，才算发送成功。...* 如果不满足上述两个条件，那就一直写入失败，让生产系统不停的尝试重试，直到满足上述两个条件，然后才能认为写入成功。 * 按照上述思路去配置相应的参数，才能保证写入 Kafka 的数据不会丢失。 好！...这个要求就是保证说，每次写数据，必须是 Leader 和 Follower 都写成功了，才能算是写成功，保证一条数据必须有两个以上的副本。

    8.8K40

    我是如何将一个老系统的kafka消费者服务的性能提升近百倍的？

    答案也不难，topic分片之后，生产者定制分发策略，保证同一对象的操作请求都分发到同一个分片中，这样每个消费者就都是在按照顺序消费各自分片中的数据啦~ 如果再加上一些条件： 这个消费者消费速度极慢、慢到需要...100ms才能处理完一条消息，即使topic分100片也不满足不了要求； 每个对象的操作请求数量存在严重倾斜的现象，有的分片消息数量很大，有的分片消息量很少，可能有的分片一直积压、有的分片却很闲； 请求操作很重要...问业务方要了代码权限，下载了代码并走读了一遍Consumer服务的代码逻辑才发现其中玄机。 其实该业务整体交互逻辑其实很简单，从kafka获取一个消息，然后进行消费。...原先的时候，消费者从kafka拉取一条消息，然后消费完成后，给kafka一个ack应答，然后去拉取下一条消息，这样即使消费者中途宕机了，kafka依旧可以将消息分发给下一个可用的消费者去处理，可以保证请求消息不会丢失掉...总结梳理 至此呢，为了解决kafka消费者消费能力太慢场景的集群并发性能提升方案就全部设计完成了，业务要求的各种要求约束也都可以满足了，最终实现了在业务逻辑没有变的情况下，整体集群的性能提升了上百倍。

    1.2K20

    大厂都是如何处理重复消息的？

    当接收者收到 PUBREL 消息之后，它会丢弃掉所有已保存的状态，并回复 PUBCOMP。 无论在传输过程中何时出现丢包，发送端都负责重发上一条消息。...因此，接收端也需要对每一条命令消息都进行应答。...3.2 为更新的数据设前置条件（类似CAS） 给数据变更设置一个前置条件： 满足条件就更新数据 否则拒绝更新数据 更新数据时，同时变更前置条件中需要判断的数据。...于是，重复执行该操作时，由于第一次更新数据时，已变更前置条件中的判断数据，不满足前置条件，则不会再执行更新。...一般也不会有问题，因为使用我们的方法，一条具体消息，总会落到确定的库表，其重复消息也会落地同样库表。

    2.4K20
    点击加载更多

    相关资讯

    热门标签

    更多标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      腾讯云开发者

      扫码关注腾讯云开发者

      扫码关注腾讯云开发者

      领取腾讯云代金券

      热门产品

      热门推荐

      更多推荐

      Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

      深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 粤公网安备44030502008569号

      腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号

      领券