关于事件通知开源的信息

本篇文章给大家谈谈事件通知开源，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享事件通知开源的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、开源的分布式协调服务—Zookeeper
• 2、优秀的国产高性能TCP/UDP/HTTP开源网络通信框架——HP-Socket
• 3、基于事件驱动的高性能开源网络库libevent介绍及安装
• 4、开源鸿蒙系统能打电话了！OpenHarmony 离手机OS越来越近

开源的分布式协调服务—Zookeeper

名词概念

Zookeeper集群中有三种角色：Leader、Follower、Observer。Leader提供读和写服务。Follower和Observer能提供读服务。Observer和Follower的区别就在于Ovserver不参与Leader选举，不参与写操作的过半成功策略。

客户端会话，一个客户端连接是指客户端和服务端之间的一个TCP长连接。客户端启动的时候，首先会和服务器建立一个TCP长连接，从第一次建立连接开始，会话（session）的生命周期就开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求，同时还能接受服务器的Watch事件通知。

Zookeeper数据模型中的一个单元，我们称之为数据节点。Zookeeper将所有数据存储在内存中，数据模型是一棵树，由斜杠进行分割的路径，就是一个Znode。如/app。每个Znode都能保存自己的数据内容，还会保存属性信息。
4. 版本

每个Znode都有一个叫作Stat的数据结构，Stat里记录了Znode的三个数据版本，分别是version（当前Znode的版本）、cversion（当前Znode子节点的版本）、aversion（当前Znode的ACL版本）
5. Watcher（事件监听器）

Watcher是Zookeeper中一个很重要的特性，Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端，该机制是Zookeeper实现分布式协调服务的重要特性。
6. ACL

Zookeeper采用ACL策略来进行权限控制，它定义了五种权限：

注意：CREATE和DELETE这两种权限是针对子节点的权限控制

连接成功之后，系统会输出Zookeeper的相关环境及配置信息等信息

很少直接使用了，接口介绍省略

ZkClient是github上一个开源的zookeeper客户端，在原生API的基础上进行了包装，更加易用。同时还实现了如Session超时重连、Watcher反复注册等功能。

直接上代码：

Curator是Netflix公司开源的客户端框架。它实现了连接重连、Watcher反复注册、重试策略和NodeExistsException异常解决等等。

直接上代码：

优秀的国产高性能TCP/UDP/HTTP开源网络通信框架——HP-Socket

HP-Socket是国人开发的一套高性能的TCP/UDP/HTTP网络通信框架，包含了服务端、客户端以及Agent组件，可用于各种不同应用场景的通信系统，并且提供了C/C++、C#、Delphi、E、Java、Python等编程语言接口。 HP-Socket 对通信层完全封装，应用程序不必关注通信层的任何细节；HP-Socket 提供基于事件通知模型的 API 接口，能非常简单高效地整合到新旧应用程序中。

为了让使用者能方便快速地学习和使用 HP-Socket，迅速掌握框架的设计思 想和使用方法，特此精心制作了大量 Demo 示例（如：PUSH 模型示例、PULL 模型示例、PACK 模型示例、性能测试示例以及其它编程语言示例）。HP-Socket 目前支持 Windows 和 Linux 平台。
以下来自官网提供的文档：
应用程序可以根据不同的容量要求、通信规模和资源状况等现实场景调整 HP-Socket 的 各项性能参数（如：工作线程的数量、缓存池的大小、发送模式和接收模式等），优化资源 配置，在满足应用需求的同时不必过度浪费资源。

提供官方文档的目录截图，由于文档非常详细，就不一一介绍了
下面是一张官方提供的demo项目结构，除了C/C++,还提供了C#、Delphi、E，详细的内容都在github的仓库中，感兴趣的可以去看看。
HP-Socket凭借着通用性、易用性、高性能、伸缩性可以应用到各种场景，而且官方提供了大量的Demo可供学习，以及非常详细的PDF文档，除了支持主流的编程语言，还支持E（易语言）。如果事件通知开源你有更好的推荐或者建议欢迎到评论区留言分享！

基于事件驱动的高性能开源网络库libevent介绍及安装

libevent是一个轻量级的基于事件驱动的高性能的开源网络库，并且支持多个平台，对多个平台的I/O复用技术进行了封装，当我们编译库的代码时，编译的脚本将会根据OS支持的处理事件机制，来编译相应的代码，从而在libevent接口上保持一致。

在当前的服务器上，面对的主要问题就是要能处理大量的连接。而通过libevent这个网络库，我们就可以调用它的API来很好的解决上面的问题。首先，可以来回顾一下，对这个问题的传统解决方法。

问题： 如何处理多个客户端连接

解决方案1： I/O复用技术

这几种方式都是同步I/O，即当读写事件就绪，他们自己需要负责进行读写，这个读写过程是阻塞的，而异步I/O则不需要自己负责读写，只需要通知负责读写的程序就可以了。

解决方案2： 多线程技术或多进程技术

多线程技术和多进程技术也可以处理高并发的数据连接，因为在服务器中可以产生大量的进程和线程和处理我们需要监视的连接。但是，这两种方式也是有很大的局限性的，比如多进程模型就不适合大量的短连接，因为进程的产生和关闭需要消耗较大的系统性能，同样，还要进程进程间的通信，在CPU性能不足的情况下不太适合。而多线程技术则不太适合处理长连接，因为当我们建立一个进程时，linux中会消耗8G的栈空间，如果我们的每个连接都杵着不断开，那么大量连接长连接后，导致的结果就是内存的大量消耗。

解决方案3： 常用的上述二者复合使用
上述的两种方法各具有优缺点，因此，我们可以将上述的方法结合起来，这也是目前使用较多的处理高并发的方法。多进程+I/O复用或者多线程+I/O复用。而在具体的实现上，又可以分为很多的方式。比如多线程+I/O复用技术，我们使用使用一个主线程负责监听一个端口和接受的描述符是否有读写事件产生，如果有，则将事件分发给其他的工作进程去完成，这也是进程池的理念。

在说完上述的高并发的处理方法之后，我们可以来介绍一个libevent的主要特色了。

同样，lievent也是采用的上述系统提供的select，poll和epoll方法来进行I/O复用，但是针对于多个系统平台上的不同的I/O复用实现方式，libevent进行了重新的封装，并提供了统一的API接口。libevent在实现上使用了事件驱动这种机制，其本质上是一种Reactor模式。

在Libevent中也是一样，向Libevent框架注册相应的事件和回调函数；当这些事件发生时，Libevent会调用这些回调函数处理相应的事件。

lbevent的事件支持三种，分别是网络IO、定时器和信号。定时器的数据结构使用最小堆（Min Heap），以提高效率。网络IO和信号的数据结构采用了双向链表(TAILQ)。

更多linux内核视频教程文本资料免费获取后台私信【内核】。

libevent的安装很简单，我是直接从github上clone下一个源码，然后进行编译安装的。

具体的命令是（假设你已经安装了git）：

现在的libevent版本已经到达libevent2了，其增加了多线程的支持，API函数也发生了一些微小的变化。

如果你想知道更多的API使用情况，请点击这里。

下面，就基于libevent2编写一个聊天室服务器。

设计思想： 首先创建一个套接字，进而创建一个事件对此端口进行监听，将所请求的用户组成一个队列，并监听所有的用户事件，当某个用户说话了，产生了读事件，就将该用户的发言发送给队列中的其他用户。

程序分析

需要包含的libevent函数头：

创建一个client结构体，接受连接后存放数据：

先来看下mian函数的处理：

首先，函数初始化了一个用户队列tailq，接着创建了一个socket套接字，并将套接字设定为非阻塞模式，接着对一个全局的evbase事件集合，注册了事件，事件源是listen_fd，回调函数是on_accept，事件发生的情况是EV_READ,而且标志EV_PESIST表明该事件一直存在，而后开启事件扫描循环event_base_dispatch(evbase)。

再看一下回调函数on_accpet实现：

这个回调函数的作用很显然，就是接受了一个客户端的请求，并申请好了一个client信息，将需要的内容填写好，在填写中需要注意的是，又向上述的事件集evbase中注册了一个bufferevent事件client-buf_ev,并注册了回调函数buffered_on_read,buffered_on_error，这三个函数分别是当接受后的连接发生了读或者错误事件后的执行函数。接着，将用户的client结构放入了用户的队列tailq中去。

用户的buffer可读后的执行函数：

执行函数的作用很明显，将libevent管理中的buffer数据读取出，存入本地的data数组内，然后对队列中的client进行检索，如果不是发数据的client,则将数据写入该client的buffer中，发送给该用户。这里注意的是需要反复读取buffer中的数据，防止一个读取并没有读取干净，直到读取不到数据为止。

buffer出错处理函数和上述函数差不多，功能就是出错后，结束掉保存的client结构，详细就不说了。

编译的时候记得修改Makefile中Libevent文件夹的位置

设计思想： 所谓回显服务器就是将客户端发过来的数据再发回去，这里主要也就是说明libevent的纯IO复用实现。实现方法和上面的差不多，甚至可以说更加简单。

程序和上面的聊天服务器差不多，只是在buffer可读的事件函数中，不是将用户的数据发送给其他用户，而是直接发送给用户本身。

设计思想： 上面的方法单纯使用libevent的简单函数来实现服务，但是这里，我们假设我们需要处理的客户端很少，于是我们可以使用对于每个连接我们分配一个线程这样的方式来实现对用户的服务。这种方式简单有效，一对一服务，就算业务逻辑出现阻塞也不怕。

程序分析

首先定义了一些数据结构，worker数据结构定义的是一个工作者，它包含有一个工作线程，和结束标志，需要获取的工作队列，和建立链表需要的指针。job数据结构定义的是操作一个job的方法和对象，这回到程序中，实际上就是指的是事件发生后，封装好的client结构体和处理这个结构体的方法。workqueue数据结构指的是当前的工作队列中的工作者，以及工作队列中的待完成的工作，以及互斥锁和条件变量（因为多个工作进程需要访问这些资源）。

具体的流程就是，用一个主线程监听一个套接字，并将套接字接受到的连接accept，并创建一个client数据结构保存该连接的信息，在这个client结构中注册一个bufferevent事件，注册到client-evbase上（这时候这是向client中的evbase注册了一个事件还没有进行循环这个事件集）。

接着，当监听到某个client有bufferevent事件发生，主线程就把该client结构体和需要进行的工作方法包装成一个job结构，然后把这个job扔到workqueue上去，并通知各个工作者。而后，各个工作者开着的线程就被激活了，疯狂地去workqueue上去抢工作做，某个worker拿到工作后，就可以解包job，根据job的工作说明书（job_function）操作工作对象（client）了。这里，job的工作说明有是循环client中的client-evbase，于是这样线程就会一直去监视这个连接的状态，如果有数据就这会调用回调函数进行处理。同时，这个线程也就是阻塞在这里，这对这一个连接负责。

建立workqueue需要的结构体和函数有：

主线程的on_accept函数为：

job中的工作指南为：

设计思想： 假设我们的用户很多，高并发，长连接，那么我们还是来用I/O复用和线程池实现吧，用一个控制线程通过I/O复用负责监听和分发事件，用一组线程池来进行处理事件，这样就可以灵活地将控制逻辑和业务逻辑分开了，见下述讲解。

程序分析
具体的流程和上面的差不多，用一个主线程监听一个套接字，并将套接字接受到的连接accept，并创建一个client数据结构保存该连接的信息，在这个client结构中注册一个bufferevent事件，但是这里，将事件注册到accept_evbase中，仍然用主线程进行监听。

而面对监听后出现的事件，将client和操作client的方法打包成一个job，放到上述的workqueue中去，让工作进程来完成。这样的操作和上述的差别在于上述方法将bufferevent注册到client中的evbase中，用工作线程监听，而本方法用主线程监听，工作线程负责处理监听产生的事件。

这要的差别在于两个函数 on_accept函数:

在buffered_on_read中，提交job。

在job工作指南server_job_function中就可以做你工作该做的事儿了，根据发来的信息进行数据库处理，http返回等等。

开源鸿蒙系统能打电话了！OpenHarmony 离手机OS越来越近

电子发烧友网报道（文/黄晶晶）最近OpenHarmony社区的专家连志安发表了一个视频。视频是说使用润和DAYU200开发套件，搭载OpenHarmony3.1 Release版本，能够在拨号界面打出电话，还表示这个新版本越来越像手机了。

自华为手机搭配鸿蒙系统以来，国产手机操作系统的呼声越来越高。受限于竞争的关系，其他手机厂商并没有直接采用鸿蒙系统。而在万物互联的自主操作系统的发展趋势下，OpenHarmony或许是另一大选择。

OpenHarmony是由开放原子开源基金会孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。

当然，OpenHarmony起初来自于华为的捐赠。

2020年9月，开放原子开源基金会接受华为捐赠的智能终端操作系统基础能力相关代码，随后进行开源，并根据命名规则为该开源项目命名为OpenAtom OpenHarmony(简称“OpenHarmony”)。

华为于2019年8月发布的鸿蒙系统（Harmony OS），可以说也是基于OpenHarmony的基础能力发展起来的商业版本的自有品牌的鸿蒙系统。

同样的，这两年基于OpenHarmony发展起来的操作系统已经面向家电、工业、金融等领域。

例如，2021年10月14日，美的发布了美的物联网操作系统1.0，该系统由美的与开放原子开源基金会合作推出，具有跨平台、分布式、开放性的特点。

这也是首个除华为之外的基于OpenHarmony2.0的物联网系统。

还有，中软国际与汇川技术发布了全球首款OpenHarmony工业智能操作系统,共同推进基于国产自主可控底座的工业智能化进程。

目前，唯独在智能手机领域还缺少基于OpenHarmony的手机操作系统。

如今，搭载OpenHarmony3.1 Release版本的开发套件，能够实现打电话功能了，相信又提振了大家对于OpenHarmony手机操作系统的信心。

首先我们来看硬件方面对OpenHarmony3.1的支持，这里以标准系统来看，电子发烧友网查阅，主要有Hi3516DV300,和RK3568等芯片。

Hi3516DV300是新一代Smart HD IP摄像机SOC，集成新一代ISP(Image Signal Processor)、H.265视频压缩编码器、高性能NNIE引擎，在低码率、高画质、智能处理和分析、低功耗等方面有较好的性能。可用在带屏设备上，比如带屏冰箱、车机等。这个芯片对应的开发板型号是Hi3516DV300。

瑞芯微RK3568芯片是一款定位中高端的通用型SOC，采用22nm制程工艺，集成4核arm架构A55处理器和Mali G52 2EE图形处理器，支持4K解码和1080P编码。RK3568支持SATA/PCIE/USB3.0等各类型外围接口，内置独立的NPU，可用于轻量级人工智能应用。RK3568支持安卓11和linux系统，主要面向物联网网关、NVR存储、工控平板、工业检测、工控盒、卡拉OK、云终端、车载中控等行业定制市场。这个芯片对应的开发板有润和DAYU200。

润和HH-SCDAYU200是基于Rockchip RK3568，集成双核心架构GPU以及高效能NPU；板载四核64位Cortex-A55 处理器采用22nm先进工艺，主频高达2.0GHz；支持蓝牙、Wi-Fi、音频、视频和摄像头等功能，拥有丰富的扩展接口，支持多种视频输入输出接口；配置双千兆自适应RJ45以太网口，可满足NVR、工业网关等多网口产品需求。影音 娱乐 、智慧出行、智能家居，如烟机、烤箱、跑步机等。

根据之前的介绍，润和软件的DAYU是为OpenHarmony 2.0 Canary 版本提供支持手机类的开发套件。不过，打电话功能应该是在OpenHarmony3.1版本上才实现的。

软件方面，OpenHarmony自发布以来，已经更新了几个版本。

2020年9月10日，OpenHarmony 1.0 版本正式上线，支持内存为128K到128M的终端设备；

2021年6月1日，OpenHarmony 2.0 Canary 版本宣布上线，支持内存128M以上的各种智能终端设备。与OpenHarmony 1.0不同，OpenHarmony 2.0覆盖设备范围延伸到百兆内存及以上的富媒体终端设备。

2021年10月，OpenHarmony 3.0版本发布。

2021年12月31 日OpenHarmony-v3.1-Beta 版本发布。

OpenHarmony-v3.1-Beta 在OpenHarmony 3.0 LTS的基础上，更新支持了以下能力：

标准系统OS基础能力增强： 内核提升CMA利用率特性、图形新增支持RenderService渲染后端引擎、短距离通信支持STA（Station）和SoftAP基础特性、支持地磁场的算法接口、传感器驱动模型能力增强、支持应用帐号信息查询和订阅等、全球化特性支持、编译构建支持统一的构建模板、编译运行时提供Windows/MacOS/Linux的前端编译工具链、JS运行时支持预览器、新增支持JSON处理、Eventbus、Vcard、Protobuf、RxJS、LibphoneNumber等6个JS三方库、新增时间时区管理、DFX新增支持HiSysEvent部件提供查询和订阅接口。

标准系统分布式能力增强： 包括新增支持分布式DeviceProfile特性、分布式数据管理支持跨设备同步和订阅、分布式软总线支持网络切换组网、分布式文件系统支持Statfs API能力等。

标准系统应用程序框架能力增强： 新增ArkUI自定义绘制能力和Lottie动画能力、新增包管理探秘隐式查询和多hap包安装、事件通知支持权限管理、设置通知振动、通知声音设置和查询、通知免打扰、会话类通知等。

标准系统应用能力增强： 输入法应用支持文本输入和横屏下布局显示、短信应用信息管理、联系人应用通话记录和拨号盘显示、设置应用更多设置项。

轻量系统能力增强： HiStreamer轻量级支持可定制的媒体管线框架、Linux版本init支持热插拔、OS轻内核驱动启动优化、快速启动能力支持。

简单来说，OpenHarmony 3.1版本由于支持更多的能力，比如联系人通话记录和拨号盘显示，比如支持更大内存的终端设备，才使得操作系统界面的优化和功能越来越像手机。

以OpenHarmony覆盖万物的目标来说，它可在多种终端设备上运行。既可运行在百 KB 级别的资源受限设备和穿戴类设备上，也可运行在百 MB 级别的智能家用摄像头、行车记录仪等相对资源丰富的设备上，以及 GB 级别的智能电视等设备上。我们看到从1.0发展起来，它支持的内存容量正在增大。

对于手机而言，早期的智能手机具有512MB、1GB的内存，后来是3GB的内存，现在6GB、8GB、12GB的内存成为主流趋势。要运行应用程序就必须有可使用的内存，例如像微信、图像视频APP、 游戏 等都不同的内存需求。

虽然目前演试的是平板搭载OpenHarmony打电话，但其实目前已有不少手机芯片支持鸿蒙系统。高通骁龙870、888、联发科天玑720、800等支持华为鸿蒙系统。而这些手机芯片未来支持OpenHarmony应该也是自然而然的事。

在鸿蒙系统发布的时候，外界会有安卓套壳的质疑？在开发者论坛上，有资料指出，华为HarmonyOS能够运行安卓的应用程序，主要是由于HarmonyOS 实现了现有Android生态应用（即AOSP）的运行。

而OpenHarmony 用户应用程序基于全新设计的 OpenHarmony API/SDK 开发，可以运行在基于 OpenHarmony 开源项目开发的系统上，并可以在多终端之间无缝流转。

OpenHarmony 程序框架仅支持 OpenHarmony 用户应用程序运行，不支持基于安卓 API/SDK 开发的用户应用程序运行。

因此，OpenHarmony更不存在“安卓套壳”这种说法。而是鼓励开发者开发属于OpenHarmony的应用程序。

在繁荣开源生态方面，去年底的一次会议上，OpenHarmony项目群生态建设组组长朱其罡表示：未来，OpenHarmony 将与主流芯片厂家开展深度合作，逐步实现代码进入社区主干，OpenHarmony 项目群将联合成员单位及工作组提供专项技术支持，预计在2022 年 9月底前与20家主流芯片达成深度合作。随着主流芯片代码进入主干，未来将产生更多的 OpenHarmony 开发板，融合各行业需求，加快技术演进，促进各类终端产品陆续在各行业呈现。

小结：

OpenHarmony以覆盖万物为目标，其中必然绕不开智能手机，这也是万众瞩目的。实际上，OpenHarmony 2.0已具备所有支撑智能手机的能力，包括库和API 接口，此次3.1版本的功能优化，对智能手机的能力进一步的增强。目前尚不知有哪些手机厂商或者第三方厂商会率先推出基于OpenHarmony的智能手机操作系统。如果读者朋友们有进一步的消息，也欢迎向我们爆料。

关于事件通知开源和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件通知开源的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、事件通知开源的信息别忘了在本站进行查找喔。