科技新闻

简介 MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 概念介绍 RabbitMQ 是目前流行的开源消息队列系统，用Erlang语言开发。RabbitMQ 是AMQP（高级消息队列）的标准实现。下面是它的几个关键概念： Broker： 简单来说就是消息队列服务器实体。 Exchange： 消息交换机，它指定消息按什么规则，路由到哪个队列。 Queue： 消息队列载体，每个消息都会被投入到一个或多个队列。 Binding： 绑定，它的作用就是把exchange和queue按照路由规则绑定起来。 Routing Key： 路由关键字，exchange根据这个关键字进行消息投递。 vhost： 虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 producer： 消息生产者，就是投递消息的程序。 consumer： 消息消费者，就是接受消息的程序。 channel： 消息通道，在客户端的每个连接里，可建立多个channel

飞书提供了丰富的api来实现消息的通知，包括文本消息、图片消息、富文本消息，本次介绍使用飞书api发送富文本消息，以下是实现思路 飞书API地址： https://open.feishu.cn/document/ukTMukTMukTM/uITNz4iM1MjLyUzM 实现思路 1.根据正则获取监控项id，需要在动作中定义报警信息 2.根据获取的监控项id构造请求获取图片地址，并下载到本地 3.需要获取三个授权凭证 app_access_token ：访问App资源相关接口。 tenant_access_token ：访问企业资源相关接口。 user_access_token ：访问用户资源相关接口。 4.根据zabbix报警的收信人手机号获取user_id，用于后面在群里@相关负责人，或者直接发给某个责任人 5.chat_id用于发送给指定的群，这里我提供两种方法获取chat_id，后面会介绍 6.上传本地图片到飞书，并获取img_key，image_key用于发送图片信息 7.传入zabbix报警消息，并艾特相关负责人发送到飞书群里或者个人 获取itemID 利用正则匹配报警信息中的itemID def get_itemid(): #获取报警的itemid itemid=re.search(r'ITEM ID:(\d+)',sys.argv[3]).group(1)

组件发送的对象都必须实现IMessage接口,通过实现接口来描述一个对象的序列化过程;自定义读写流的好处就是可以得到更好的性能,但缺点也相对明显的就是工作量比较多.在很多应用场合下所追求的并不是性能第一,而是希望省下这些烦锁的工作,为了应付这种需要组件可以实现一个简单的消息适配器来完成这样的功能.下面通过扩展的方式来实现组件对.net二进制序列化对象转输的支持. 定义协议格式 在TCP下进行数据交互通讯首先是要制定一个通讯的应用协议,由于组件提供基于结束符和头大小描述的基础分析器,可以从这基础分析协中派生下来.似下通过一个图来描述协议的具体细节 协议描述比较简单消息头是4个字节用于存储消息的总长度,而序列化存储的数据则是总长度减去头4位. 实现具体的分析器和消息适配器 协议制定后就可以进行分析器的实现,由于采用头4字节描述大小,所以分析器从HeadSizeOfPackage基础类派生下载重写相关方法即可;完整实现代码如下: public class BinaryFormatterPackage:HeadSizeOfPackage { public BinaryFormatterPackage() { } public BinaryFormatterPackage(TcpChannel channel) : base(channel) { } public override

Kafka中的消息是以主题为基本单位进行归类的，各个主题在逻辑上相互独立。每个主题又可以分为一个或多个分区。 不考虑多副本的情况，每个分区对应一个日志（Log），每个日志包含多个日志分段（LogSegment），对应到物理存储，可以理解为Log对应日志一个目录，每个LogSegment对应一个日志文件和两个索引文件，以及可能的其他可能文件（比如事务索引文件）。 举例说明，假设有名为topic-log的主题，此主题有4个分区，那么在实际物理存储上表现如下图。 1. __consumer_offsets- * 如图中绿色标记部分，用来保存客户端消费消息之后提交的消费位移，以便在机器重启或者宕机恢复之后正确得知客户端消费消息的位置。（不是本章重点，不再赘述） 2. Log目录 图中蓝色标记部分，可以理解为每个分区对应一个目录。本例中topic-log主题包含四个分区，所以有"topic-log-0"，“topic-log-1”，“topic-log-2”，"topic-log-3"这4 个文件夹。 3. 检查点文件 与Log目录平级的，存在4个检查点文件，用于日志的compaction。 cleaner-offset-checkpoint文件是 清理检查点文件 ，记录每个主题的每个分区中已经清理的偏移量，如下图（下文介绍日志压缩时会详细阐述） 4. 日志分段

前提 之前有个打算在学习RabbitMQ之前，把AMQP详细阅读一次，挑出里面的重点内容。后来找了下RabbitMQ的官方文档，发现了有一篇文档专门介绍了RabbitMQ中实现的AMQP模型部分，于是直接基于此文档和个人理解写下这篇文章。 AMQP协议 AMQP 全称是Advanced Message Queuing Protocol，它是一个(分布式)消息传递协议，使用和符合此协议的客户端能够基于使用和符合此协议的消息传递中间件代理(Broker，也就是经纪人，个人感觉叫代理合口一些)进行通信。AMQP目前已经推出协议1.0，实现此协议的比较知名的产品有StormMQ、RabbitMQ、Apache Qpid等。RabbitMQ实现的AMQP版本是0.9.1，官方文档中也提供了该协议pdf文本下载，有兴趣可以翻阅一下。 消息中间件代理的职责 Messaging Broker，这里称为消息中间件代理。它的职责是从发布者(Publisher，或者有些时候称为Producer，生产者)接收消息，然后把消息路由到消费者(Consumer，或者有些时候称为Listener，监听者)。 因为消息中间件代理、发布者客户端和消费者客户端都是基于AMQP这一网络消息协议，所以消息中间件代理、发布者客户端和消费者客户端可以在不同的机器上，从而实现分布式通讯和服务解耦。

1：环境在window下面的，thinkphp3.2 2：下载GatewayWork，放到 目录下 3：然后双击打开 这个文件开启服务 4：所有的逻辑均在 Events.php这个文件里面 5：当用户连接到服务器时，触发 ，初始化，发送client_id 6：收到消息时， 出发了这个方法，message，就是客户端发送过来的数据 7：附上代码 /** * 当客户端发来消息时触发 * @param int $client_id 连接id * @param mixed $message 具体消息 */ public static function onMessage($client_id, $message) { //1：收到消息之后转成array() $data = json_decode($message,true); if(!$data){ return; } //2:判断类型，bind是client_id与用户id绑定 //say 发送消息的事件 switch ($data['type']) { //绑定 case 'bind': $from_id = $data['from_id']; //把获取的到用户id与client_id进行绑定 Gateway::bindUid($client_id,$from_id); return; //发送文字消息 case 'say': /

简言之 ：观察者模式(Observer),当一个对象状态发生改变时，依赖它的对象全部会收到通知，并自动更新。 具体描述 ：一个对象通过添加一个方法（该方法允许另一个对象-观察者，注册自己）使本身变得可观察。当可观察的对象更改时，它会将消息发送到已注册的观察者。这些观察者使用该信息执行的操作与可观察的对象无关。结果是对象可以相互对话，而不必了解原因。观察者模式是一种时间系统，意味着这一模式允许某个类观察另一个类的状态。当被观察的类状态发生改变的时候，观察类可以收到通知并且做出相应的动作，观察者模式避免组件之间的紧密耦合。 观察者模式中的角色 ： Subject(抽象主题角色)：主题角色将所有观察者对象的引用保存在一个集合中，每个主题可以有任意多个观察者。抽向主题提供了增加和删除观察者对象的接口。 Observer（抽象观察者角色）：为所有的具体观察者定义一个接口，在观察的主题发生改变时更新自己。 ConcreteSubject（具体主题角色）：存储相关状态到具体观察者对象，当具体主题的内部状态改变时，给所有登记过的观察者发出通知，具体主题角色通常用一个具体子类实现。 ConcreteObserver（具体观察者角色）：存储一个具体主题对象，存储相关状态，实现抽象观察者角色所要求的更新接口，以使得其自身状态和主题的状态保持一致。 推荐阅读代码： PHP设计模式之观察者模式

Netty常用的几种解码器 Decoder解码器 ByteToMessageDecoder 将byte数据转换为一个消息类 方法名称 描述 Decode 这是您需要实现的唯一抽象方法。通过具有输入字节的ByteBuf和添加了已解码消息的List进行调用。重复调用encode（），直到列表返回时为空。然后将List的内容传递到管道中的下一个处理程序。 decodeLast 所提供的默认实现只调用了decode（）。当Channel变为非活动状态时，此方法被调用一次。提供特殊的替代 举个例子： 假设我们接收一个包含简单整数的字节流,每个都单独处理。在本例中,我们将从入站 ByteBuf 读取每个整数并将其传递给 pipeline 中的下一个ChannelInboundHandler。“解码”字节流成整数我们将扩展ByteToMessageDecoder，实现类为“ToIntegerDecoder” public class ToIntegerDecoder extends ByteToMessageDecoder { @Override public void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception { if (in.readableBytes() >= 4) {

飞书提供了丰富的api来实现消息的通知，包括文本消息、图片消息、富文本消息，本次介绍使用飞书api发送文本消息，以下是实现思路 飞书API地址： https://open.feishu.cn/document/ukTMukTMukTM/uITNz4iM1MjLyUzM 实现思路 1.需要获取三个授权凭证 app_access_token ：访问App资源相关接口。 tenant_access_token ：访问企业资源相关接口。 user_access_token ：访问用户资源相关接口。 2.根据zabbix报警的收信人手机号获取user_id，用于后面在群里@相关负责人，或者直接发给某个责任人 3.chat_id用于发送给指定的群，这里我提供两种方法获取chat_id，后面会介绍 4.传入zabbix报警消息，并艾特相关负责人发送到飞书群里或者个人 获取授权凭证 1.获取 App ID 和 App Secret 登录开发者后台，在“我的应用”页面创建企业自建应用。进入企业自建应用详情页，获取App ID和App Secret。 2.获取 tenant_access_token 一种方法是通过企业自建应用方式获取，另一种是通过应用商店应用获取，这里我使用第一种方法，直接创建应用即可 3.创建完应用后可根据APP ID和 App Secret构造请求获取 def gettenant

现今，“数据泄露事件”、“企业数据信息安全”、“网络环境下数据安全”、“企业数据防泄漏”……等都成为互联网时代的相关热门话题，也是国内政企机构等重点关注的问题。为什么数据泄露事件以及信息安全保护工作得到了如此广泛的关注？近年来，可能大家多多少少都关注到互联网新闻中经常会报道出某某企业数据泄露，什么什么公司的数据泄露导致数据在网络上售卖等等，这都给互联网的企业以及个人敲响了警钟，加强了对数据安全的关注程度，想要通过寻求某种方法，来切实有效的保证数据文件在流通使用中的安全，防止自身的企业发生数据泄露事件。因此，针对目前的互联网环境， 企业文件加密 工作的进行刻不容缓！ 知识经济、知识版权时代，互联网企业之间的竞争都是知识产权与版权所有之间的竞争，一旦企业在发展以及管理过程中出现纰漏，造成自身企业泄露，轻则会造成企业经济损失，重则会影响企业的形象，造成企业在后期未来市场竞争力衰退，甚至影响到企业的生死存亡。因此，企业数据防泄漏系统的使用对于企业来说尤为重要，且具有其必要性！ 针对企事业单位的发展现状，目前企业所面临的数据泄露危机增多，并且泄露的根源也在不断增强，那么对于这样的情况，企业的数据防泄漏工作应该如何进行？企业文件加密软件又要如何的使用和选择？ 对于目前的企事业单位来说，具备了一定的安全意识的前提下，其次就是要去选择安全实用的文件加密软件来实现对企业环境下数据文件的保护工作