OpenHarmony4.0源码解析之分布式硬件管理框架

于 2024-08-26 16:49:39 发布
阅读量430 收藏 12
点赞数 7
分类专栏： 鸿蒙 OpenHarmony 前端 文章标签： 分布式 harmonyos 华为 鸿蒙南向开发 鸿蒙
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/HarmonyOS_666/article/details/141568202
版权
鸿蒙 同时被 3 个专栏收录
303 篇文章 3 订阅
订阅专栏
前端
301 篇文章 0 订阅
订阅专栏
OpenHarmony
19 篇文章 0 订阅
订阅专栏

概述

分布式硬件管理框架（dhfwk）是为分布式硬件子系统提供信息管理能力的部件。dhfwk 为分布式硬件子系统提供统一的分布式硬件接入、查询和使能等能力。例如分布式相机，分布式屏幕，分布式音频等部件都需要 dhfwk 进行统一的管理。dhfwk 的核心功能主要包括两部分：

  • 设备上线后，注册并初始化设备的分布式硬件能力，如相机，音频等。
  • 设备下线后，清理并释放分布式硬件资源。

本文将从设备上下线时对分布式硬件的处理逻辑流程入手，简要介绍 dhfwk 的工作原理。下文中 设备 指开发板，部件 指分布式硬件，如分布式相机，麦克风等。

系统架构

dhfwk 的系统架构图如下所示：

image.png

如上图所示，dhfwk 主要包括以下六个部件：

  • ResourceManager：对接分布式数据服务，用于存储信任体系内，本机和周边设备同步过来的设备硬件信息。
  • VersionManager：用于管理超级终端内，各个设备的分布式硬件平台和分布式硬件部件的版本号，供分布式硬件业务各个部件业务使用。
  • AccessManager：用于部件接入控制，设备上下线时触发对应的逻辑。
  • ComponentManager：对接各分布式硬件实例化的部件，实现对部件的动态加载和使能/去使能等操作。
  • ComponentLoader：用于解析部件配置文件，按需加载部件驱动的实现 so，获取驱动外部接口函数句柄以及实现版本，供其他业务使用。
  • LocalHardwareManager：用于采集本地硬件信息，并通过 ResourceManager 进行硬件信息的持久化存储；同时，通过对接硬件驱动，用于感知本地硬件的插拔等操作，感知是否新增或移除可用硬件，将动态变化的硬件设备也纳入分布式硬件管理。

分布式硬件实质是在本地使用对端设备的硬件能力，为了抽象这一场景，我们引入**主控端 和 被控端**的概念：

  • 主控端(source)：借助于具体部件的实现（如 daudio）调用被控端部件的能力，如播放音频，录音等。
  • 被控端(sink)：通过具体的部件实现接收主控端的命令，调用本地硬件完成命令并将数据返回给主控端。

双端通信的细节由各部件内部实现，此处不再展开。

服务启动

dhfwk 对应的系统服务是 dhardware，该服务随设备开机启动，主要负责对可信设备上下线及本地硬件设备改动进行监听并作出相应。

void DistributedHardwareService::OnStart()
{
    Init();
}

bool DistributedHardwareService::Init()
{
    Publish(this);
    AccessManager::GetInstance()->Init(); 
    return true;
}

通过上述代码我们可以看到，服务启动时会初始化 AccessManager 以监听可信设备的上下线。

注意：文中代码片段均经过修改，仅保留核心逻辑片段，删除日志输出，错误处理等非核心代码！

AccessManager 的初始化主要包括三步，初始化设备管理器 DeviceManager，注册设备状态变化监听回调，以及向其他在线设备发送上线通知并处理对应的分布式硬件注册工作。

int32_t AccessManager::Init()
{
    DeviceManager::GetInstance().InitDeviceManager(DH_FWK_PKG_NAME, shared_from_this());
    DeviceManager::GetInstance().RegisterDevStateCallback(DH_FWK_PKG_NAME, "", shared_from_this());
    SendTrustedDeviceOnline();
    return DH_FWK_SUCCESS;
}

我们可以看到，上述代码将 shared_from_this() 作为参数传递给了 DeviceManager::RegisterDevStateCallback()。这是因为 AccessManager 继承了类 DmInitCallback 和 DeviceStateCallback ，并实现了 ``OnDeviceOnline()， OnDeviceReady()， OnDeviceOffline()等方法以实现 DeviceManager 监听到可信设备状态变化时可以通知到 AccessManager` 并处理对应的分布式硬件上下线逻辑。

SendTrustedDeviceOnline() 方法会通过 DeviceManager 扫描在线可信设备，并触发设备上线相关逻辑。具体参考下文。

设备上线

触发设备上线逻辑共有两种情况：

  • 本机服务启动，SendTrustedDeviceOnline() 方法中扫描到了有其他在线的可信设备。
  • DeviceManager 监测到其他设备上线，触发 AccessManager::OnDeviceReady() 回调。
void AccessManager::SendTrustedDeviceOnline()
{
    std::vector<DmDeviceInfo> deviceList;
    DeviceManager::GetInstance().GetTrustedDeviceList(DH_FWK_PKG_NAME, "", deviceList);
    for (const auto &deviceInfo : deviceList) {
        const auto networkId = std::string(deviceInfo.deviceId);
        const auto uuid = GetUUIDBySoftBus(networkId);
        DistributedHardwareManagerFactory::GetInstance().SendOnLineEvent(networkId, uuid, deviceInfo.deviceTypeId);
    }
}

void AccessManager::OnDeviceReady(const DmDeviceInfo &deviceInfo)
{
    auto networkId = std::string(deviceInfo.deviceId);
    uuid = GetUUIDBySoftBus(networkId);
  	DistributedHardwareManagerFactory::GetInstance().SendOnLineEvent(networkId, uuid, deviceInfo.deviceTypeId);
}

上面两种情况最终都会调用 DistributedHardwareManagerFactory::GetInstance().SendOnLineEvent() 方法。DistributedHardwareManager 会对架构部分提到的六大组件进行统一的管理。

初始化

首次调用 DistributedHardwareManagerFactory 的方法时，会先检测是否初始化完成，若为初始化会先初始化 DistributedHardwareManager。DistributedHardwareManagerFactory 是 DistributedHardwareManager 的工厂类，其方法调用最终都会调用到 DistributedHardwareManager。

int32_t DistributedHardwareManager::Initialize()
{
    VersionInfoManager::GetInstance()->Init();
    ComponentLoader::GetInstance().Init();
    VersionManager::GetInstance().Init();
    ComponentManager::GetInstance().Init();
    CapabilityInfoManager::GetInstance()->Init();
    LocalHardwareManager::GetInstance().Init();

    return DH_FWK_SUCCESS;
}

由上面代码我们可以看到，DistributedHardwareManager 初始化时会依次对几个核心部件进行初始化。其中 VersionInfoManager 和 CapabilityInfoManager 隶属于 ResourceManager。这两者的初始化主要完成对应的数据库组件 DBAdapter 的初始化，这里不再详细介绍。

1.ComponentLoader 初始化

ComponentLoader 的初始化主要完成分布式硬件对应的 so 库加载。主要包括以下三种：

  • source_handler：设备作为主控端时提供给 dhfwk 的接口，包括部件主控端的初始化等接口。
  • sink_handler：设备作为被控端时提供给 dhfwk 的接口，包括部件主控端的初始化等接口。
  • hardware_handler：部件提供给 dhfwk 的接口，用于本地硬件信息的处理。

ComponentLoader 在初始化时会读取系统配置文件 /vendor/etc/distributedhardware/distributed_hardware_components_cfg.json。该文件定义了设备当前支持的分布式硬件及其相关 so 库的路径，saId 等信息，如下样例所示：

{
    "distributed_components": [
        {
            "name": "distributed_audio",
            "type": "AUDIO",
            "comp_handler_loc": "libdistributed_audio_handler.z.so",
            "comp_handler_version": "1.0",
            "comp_source_loc": "libdistributed_audio_source_sdk.z.so",
            "comp_source_version": "1.0",
            "comp_source_sa_id": 4805,
            "comp_sink_loc": "libdistributed_audio_sink_sdk.z.so",
            "comp_sink_version": "1.0",
            "comp_sink_sa_id": 4806
        },
        {
            "name": "distributed_camera",
            "type": "CAMERA",
            "comp_handler_loc": "libdistributed_camera_handler.z.so",
            "comp_handler_version": "1.0",
            "comp_source_loc": "libdistributed_camera_source_sdk.z.so",
            "comp_source_version": "1.0",
            "comp_source_sa_id": 4803,
            "comp_sink_loc": "libdistributed_camera_sink_sdk.z.so",
            "comp_sink_version": "1.0",
            "comp_sink_sa_id": 4804
        }
}

从上述文件中解析出分布式硬件对应的 so 后，调用 dlopen() 完成加载。同时，会用文件中的 version 字段初始化相应的部件版本。VersionManager 主要负责管理部件版本，初始化阶段会调用 ComponentLoader::GetLocalDHVersion() 初始化相应版本信息。

2.ComponentManager 初始化

ComponentManager 主要负责对各个部件进行管理，如初始化，使能，去使能等。其初始化会通过上一步中加载的各部件的 source_handler 和 sink_handler 调用到部件具体的初始化入口。其核心逻辑如下

int32_t ComponentManager::Init()
{
	InitCompSource();
    InitCompSink();

    auto sourceResult = StartSource();
    auto sinkResult = StartSink();

    WaitForResult(Action::START_SOURCE, sourceResult);
    WaitForResult(Action::START_SINK, sinkResult);

    return DH_FWK_SUCCESS;
}

InitCompSource()/InitCompSink() 会调用 ComponentLoader 的 GetAllCompTypes(),GetSink(),GetSource() 接口，从相应的 so 中加载部件的 source_handler/sink_handler 实例，然后将实例本地存储。

StartSource()/StartSink() 则会调用各部件 handler 的 InitSource()/InitSink() 方法进入部件内部的相关初始化，具体的初始化包括部件相关的 sa，虚拟驱动服务等加载。如下以 StartSink() 代码为例：

ActionResult ComponentManager::StartSink()
{
    std::unordered_map<DHType, std::shared_future<int32_t>> futures;
    std::string uuid = DHContext::GetInstance().GetDeviceInfo().uuid;
    for (const auto &item : compSink_) {
        CompVersion compversion;
        VersionManager::GetInstance().GetCompVersion(uuid, item.first, compversion);
        auto params = compversion.sinkVersion;
        auto future = std::async(std::launch::async, [item, params]() { return item.second->InitSink(params); });
        futures.emplace(item.first, future.share());
    }
    return futures;
}

因为 InitSource()/InitSink() 的调用是通过异步任务实现的。因此还需要使用 WaitForResult() 阻塞线程等待部件初始化完成。

3.LocalHardwareManager 初始化

LocalHardwareManager 主要负责采集并存储本地硬件信息以及检测本地硬件的改动。与 source_handler/sink_handler 类似，LocalHardwareManager 初始化时调用 ComponentLoader 的 GetAllCompTypes(),GetHardwareHandler() 接口获取各部件的 hardware_handler 实例，然后调用实例的 Initialize() 接口完成初始化。

接着需要调用 hardware_handler->Query() 接口查询本地设备存在的硬件。并通过 CapabilityInfoManager::AddCapability() 接口将硬件信息存储在数据库。

最后调用 hardware_handler->IsSupportPlugin() 接口查询硬件是否支持热插拔，若支持热插拔，则调用 hardwareHandler->RegisterPluginListener() 注册硬件插拔事件监听回调。回调中监听到插拔事件后调用 CapabilityInfoManager::AddCapability() 和 CapabilityInfoManager::RemoveCapabilityInfoByKey() 接口更新存储的硬件信息。

具体代码参考以下：

void LocalHardwareManager::Init()
{
    std::vector<DHType> allCompTypes = ComponentLoader::GetInstance().GetAllCompTypes();
    for (auto dhType : allCompTypes) {
        IHardwareHandler *hardwareHandler = nullptr;
        ComponentLoader::GetInstance().GetHardwareHandler(dhType, hardwareHandler);

        hardwareHandler->Initialize();

        QueryLocalHardware(dhType, hardwareHandler);

        if (!hardwareHandler->IsSupportPlugin()) {
            ComponentLoader::GetInstance().ReleaseHardwareHandler(dhType);
            hardwareHandler = nullptr;
        } else {
            std::shared_ptr<PluginListener> listener = std::make_shared<PluginListenerImpl>(dhType);
            hardwareHandler->RegisterPluginListener(listener);
        }
    }
}

void LocalHardwareManager::QueryLocalHardware(const DHType dhType, IHardwareHandler *hardwareHandler)
{
    std::vector<DHItem> dhItems;
    dhItems = hardwareHandler->Query();

    std::vector<std::shared_ptr<CapabilityInfo>> capabilityInfos;
    for (auto dhItem : dhItems) {
        std::shared_ptr<CapabilityInfo> dhCapabilityInfo = 
            std::make_shared<CapabilityInfo>(dhItem.dhId, deviceId, devName, devType, dhType, dhItem.attrs);

        capabilityInfos.push_back(dhCapabilityInfo);
    }
    CapabilityInfoManager::GetInstance()->AddCapability(capabilityInfos);
}

部件使能

如前文所述，首次调用 DistributedHardwareManagerFactory 的方法时，会进行上述初始化流程。初始化完成后继续进行 DistributedHardwareManager::SendOnLineEvent() 的上线操作。

dhfwk 中封装了自己的 task 类，同时使用 TaskFactory 对任务进行统一管理，task 框架的实现此处不详细介绍。我们仅介绍设备上线流程中涉及到的 online_task 和 enable_task 两种任务。

如上述，DistributedHardwareManager::SendOnLineEvent() 方法中会创建一个 online_task 去完成上线流程。online_task 首先会通过分布式 KVStore 和对端设备同步版本及硬件能力信息，然后读取相关信息并本地记录。

void OnLineTask::DoSyncInfo()
{
    CapabilityInfoManager::GetInstance()->ManualSync(GetNetworkId());
    VersionInfoManager::GetInstance()->ManualSync(GetNetworkId());

   	CapabilityInfoManager::GetInstance()->SyncDeviceInfoFromDB(GetDeviceIdByUUID(GetUUID()));
    VersionInfoManager::GetInstance()->SyncVersionInfoFromDB(GetDeviceIdByUUID(GetUUID()));
}

完成信息同步后 online_task 会创建使能任务 enable_task 完成部件使能，设备使能主要是完成主控端的初始化，包括创建本地适配器，在本地注册分布式硬件，使设备可以通过和使用本地硬件相同的方法使用分布式硬件。

enable_task 则通过 ComponentManager::Enable() 接口进行使能操作。ComponentManager 则调用独立的使能模块 ComponentEnable 中的 Enable 接口完成使能。该接口调用之前加载的 source_handler 的 RegisterDistributedHardware() 接口完成部件使能。

完成部件使能后，设备上线的整体流程就结束了，完整调用流程可参考下面时序图。

[图片上传失败…(image-5eb467-1724661938376)]

设备下线

当 DeviceManager 监测到对端设备下线时，会触发 AccessManager::OnDeviceOffline() 回调执行设备下线逻辑。设备下线流程上和设备上线刚好相反，首先会对所有的分布式硬件去使能。若所有的可信设备都已下线，还会触发 DistributedHardwareManager::Release() 释放相关资源。

部件去使能

去使能的流程与使能相似，设备下线时会创建 offline_task，下线任务的执行与上线任务相反，首先创建 disable_task 对部件去使能，然后调用 CapabilityInfoManager::RemoveCapabilityInfoInMem() 方法移除记录的硬件能力信息。

disable_task 调用 ComponentManager::Disable() 接口，然后由去使能模块 ComponentDisable 的 Disable() 接口调用 source_handler 的 UnregisterDistributedHardware() 接口完成去使能。该操作主要是从系统中移除分布式硬件。

资源释放

在 DistributedHardwareManagerFactory::SendOffLineEvent() 方法中，完成设备下线任务后，如果监测到所有可信设备均已下线，则会触发资源释放流程以减少系统负载。

int32_t DistributedHardwareManagerFactory::SendOffLineEvent(const std::string &networkId, const std::string &uuid,
    uint16_t deviceType)
{
    DistributedHardwareManager::GetInstance().SendOffLineEvent(networkId, uuid, deviceType);
    DHContext::GetInstance().RemoveOnlineDevice(uuid);
    if (DistributedHardwareManager::GetInstance().GetOnLineCount() == 0) {
        DHLOGI("all devices are offline, start to free the resource");
        UnInit();
    }
    return DH_FWK_SUCCESS;
}

上述 UnInit() 方法会调用到 DistributedHardwareManager::Release() 方法，该方法释放资源的流程与 DistributedHardwareManager::Initialize() 正好相反。

int32_t DistributedHardwareManager::Release()
{
    TaskBoard::GetInstance().WaitForALLTaskFinish();
    LocalHardwareManager::GetInstance().UnInit();
    CapabilityInfoManager::GetInstance()->UnInit();
    ComponentManager::GetInstance().UnInit();
    VersionManager::GetInstance().UnInit();
    ComponentLoader::GetInstance().UnInit();
    VersionInfoManager::GetInstance()->UnInit();

    return DH_FWK_SUCCESS;
}

首先调用 TaskBoard::GetInstance().WaitForALLTaskFinish() 阻塞线程等待所有异步任务完成。然后按照和 Initialize() 正好相反的顺序释放组件资源。

组件的释放流程大体和初始化相反，如 LocalHardwareManager 和 VersionManager 会清除本地记录的硬件及版本信息，CapabilityInfoManager 和 VersionInfoManager 会释放 DBAdapter 实例。这里我们不在详细介绍，下面简单介绍一下 ComponentManager 和 ComponentLoader 的释放流程。

1.ComponentManager 释放

从前文初始化阶段我们知道，ComponentManager 初始化时会获取并记录 source_handler 和 sink_handler，然后调用它们的 InitSource() 和 InitSink() 接口进行 sa 及虚拟驱动服务的加载以完成初始化。

同样地，在释放阶段，首先会调用 source_handler 和 sink_handler 的 ReleaseSource() 和 ReleaseSink() 接口。该接口主要释放部件内部地资源，如 sa 的 unload 操作(4.0 版本新增)，虚拟驱动服务的卸载等。

2.ComponentLoader 释放

ComponentLoader 的释放比较简单，主要是通过 dlclose() 释放初始化阶段加载的各分布式硬件的 source_handler，sink_handler 和 hardware_handler。

小结

以上就是 dhfwk 的核心工作原理，本文忽略一些具体的实现细节，从整体流程上介绍了服务启动，设备上线，设备下线的核心流程及原理。

写在最后

有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（OpenHarmony）资料用来跟着学习是非常有必要的。

想更深入的学习 OpenHarmony （鸿蒙南向）全栈开发的内容可点击领取一下学习文档，限时开源，先到先得~无套路领取！！

请点击→《鸿蒙南向开发学习路线》

OpenHarmony入门学习视频

image.png

鸿蒙南向开发实战教学视频

image.png

获取以上完整鸿蒙HarmonyOS学习文档，请点击→《鸿蒙南向开发学习路线》
《OpenHarmony源码解析》：
  • 搭建开发环境
  • Windows 开发环境的搭建
  • Ubuntu 开发环境搭建
  • Linux 与 Windows 之间的文件共享
  • ……
    image.png
系统架构分析：
  • 构建子系统
  • 启动流程
  • 子系统
  • 分布式任务调度子系统
  • 分布式通信子系统
  • 驱动子系统
  • ……
    image.png
OpenHarmony面试题（内含参考答案）

image.png

获取以上完整鸿蒙HarmonyOS学习文档，请点击→《鸿蒙南向开发学习路线》

在这里插入图片描述

鸿蒙初辟梦创道远
关注
  • 7
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
浅谈Openharmony系统服务框架Samgr
DaHuangXiao的博客
04-09 3843
前言 在刚接触 Samgr 时笔者根本不知道其设计初衷是啥（水平较菜，刚接触C语言），尽管官方文档对其进行了介绍，但仍有种听君一席话胜读一席话的感觉。为此，笔者花了一天对其进行探究和学习，将笔记梳理并记录于本文。 Samgr概念 官方说明 官方仓 https://gitee.com/openharmony/distributedschedule_samgr_lite 对其解释如下: 由于平台资源有限，且硬件平台多样，因此需要屏蔽不同硬件架构和平台资源的不同、以及运行形态的不同，提供统一化的系统服务开发框架。
rk3568 OpenHarmony4.0如何使用中文输入法
04-30
在rk3568上运行OpenHarmony4.0，意味着我们可以充分利用其硬件优势来实现流畅的输入法体验。 中文输入法在OpenHarmony中的实现通常依赖于输入法引擎（IME，Input Method Engine）。IME是操作系统与硬件之间的一个...
OpenHarmony4.0源码解析之媒体框架
HarmonyOS_666的博客
08-26 566
媒体框架 multimedia_player_framework 主要提供音视频的录制与播放功能。
OpenHarmony4.0源码解析之电源管理的熄屏和休眠机制
最新发布
HarmonyOS_666的博客
08-26 470
本文主要分析电源管理服务组件的息屏、休眠的关键流程代码，其他流程将在后续的系列文章中描述。其中，电源管理接口和运行锁接口相关内容不再赘述。文中涉及到 HDF 驱动框架、SystemAbility 框架等内容只是简单提及,不做详细分析。
【鸿蒙南向开发】OpenHarmony 4.0 分布式软总线解析：设备发现与传输
HarmonyOS_666的博客
07-18 937
这份鸿蒙（HarmonyOS NEXT）文档包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony南向开发、鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。
OpenHarmony 4.0 分布式软总线解析：设备发现与传输
maniuT的博客
04-10 2275
OpenHarmony 的分布式软总线子系统为 OpenHarmony 系统提供的通信相关的能力，包括：WLAN 服务能力、蓝牙服务能力、软总线、进程间通信 RPC（Remote Procedure Call）等通信能力。下面我们通过阅读 OpenHarmony 4.0 的源码，来解读一下 OpenHarmony 软总线当前的一个实现情况。
OpenHarmony 4.0 Release发布，同步升级API 10
xiangzhihong8的专栏
12-21 1233
OpenHarmony 4.0版本如期而至，开发套件同步升级到API 10。相比3.2 Release版本，新增4000多个API，应用开发能力更加丰富；HDF新增200多个HDI接口，硬件适配更加便捷；我们持续优化图形框架和方舟编译器（ArkCompiler），用户交互体验得到进一步提升；ArkUI组件定制化能力和组件动效能力也得到进一步增强；分布式硬件支持的范围扩大到音频和输入领域；分布式数据为开发者数据分享带来了全新的统一数据管理框架。
OpenHarmony 性能优化之提升应用冷启动速度
m0_70748458的博客
06-05 735
自定义组件的生命周期变更会调用相应的回调函数。aboutToAppear函数会在创建自定义组件实例后，页面绘制之前执行，以下代码在aboutToAppear中对耗时间的计算任务进行了异步处理，避免在该接口执行该耗时操作，不阻塞页面绘制。@Entry@Component// 耗时操作// 异步任务build() {// 运算任务异步处理setTimeout(() => { // 这里使用setTimeout来实现异步延迟运行。
最新OpenHarmony系统一二级目录整理
坚果的博客
03-12 1988
由于Master分支代码更新迭代速度很快，部分目录结构可能在后面会发生变化。特别是高层次的部分代码。
OpenHarmony Camera源码分析
maniuT的博客
05-21 1159
相机组件支持相机业务的开发，开发者可以通过已开放的接口实现相机硬件的访问、操作和新功能开发，最常见的操作如：预览、拍照和录像等。相机框架中主要包含会话管理、设备输入和数据输出，设备的输入和数据的输出配置都是在采集会话中完成，会话管理模块管理相机设备输入和数据输出。应用层在调用相机功能时，首先需要创建采集会话，在配置会话的过程中会将创建的设备输入和数据输出添加到采集会话中。
LCN分布式事务框架原理详解4.0
02-24
1、地址：2、4.0添加升级如下功能：（1）3.0虽然有事务补偿机制，但4.0在此基础上不仅添加事务补偿机制的策性，还添加了管理的后台可以看到补偿的数据；同时也添加了一个回调地址，可以在补偿之前可以最先知道这次...
.Net Core微服务分布式开发框架源码
10-13
一个轻量级的完全可以落地的微服务/分布式开发框架，同时也适用于单体架构系统的开发。支持经典三层与DDD架构开发模式、集成了一系列主流稳定的微服务配套技术栈。一个前后端分离的框架，前端基于Vue、后端基于.Net6...
基于Python的obEspoir分布式游戏框架设计源码
05-22
obEspoir分布式游戏框架设计源码：该项目基于Python开发，包含77个文件，主要使用Python语言。obEspoir是一款彻底分布式的开源游戏框架，采用asyncio、uvloop等异步编程技术，以保障高性能。此外，该框架从框架层面...
DDIA 分布式数据的分区与复制 - 基于 Redis、Kafka、Elasticsearch 的深入分析
凌虚Blog
08-22 952
本文通过对RedisKafka和三个常用组件的分析，展示了分布式系统中分区和复制机制的设计与实现。可以看到哈希分区是常见的选择。基于性能和复杂度的权衡，单主异步复制往往是默认配置，但为了提供更高的数据一致性，这些组件也会提供多从复制确认的方案。
推荐一款基于Spring Boot + VUE 框架开发的分布式文件管理系统，功能齐全、实用便捷（附源码）
m0_68103666的博客
08-21 689
为用户提供了一个简单、方便的文件存储和协作平台。
分布式互斥锁优化数据库压力：从基础到高级优化
heromps的博客
08-22 986
以及分布式锁分片策略，分别适用于不同的高并发场景。在实际应用中，根据具体需求和系统特点，灵活调整锁机制，是确保高并发系统稳定运行的关键。在极端高并发场景中，大量请求同时获取分布式锁，仍可能导致不必要的数据库访问。为了解决这一问题，分布式锁可以控制同一时间只有一个请求可以访问数据库，其他请求则等待锁的释放。通过将锁按一定规则进行分片（如按用户ID取模），多个线程可以同时操作不同的分片，从而大幅提升系统的并发处理能力。这一基础方案虽然简单，但已经能够大幅降低数据库的并发访问量，避免系统在高并发场景下的崩溃。
HarmonyOS 地图服务：深度解析其丰富功能与精准导航实力
白晓明的博客
08-21 1301
HarmonyOS为开发者和用户带来了强大的地图功能支持，其中包括地图组件MapComponent以及地图组件的主要功能入口类MapComponentController。
鸿蒙内核源码分析(信号生产篇) | 注意结构体的名字和作用.
黎程雨的博客
08-21 798
关于信号篇，本只想写一篇，但发现把它想简单了，内容不多，难度极大.整理了好长时间，理解了为何要单独为它开一章，原因有二
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值