`

Berkeley DB(七) -- DB Replication (HA)中部

    博客分类:
  • DB
阅读更多
Berkeley DB -- DB Replication (HA)中部


Synchronizing with a master

当一个client探测到replication组内一个新的master后,在它能去处理新的数据库变化之前,这个client必须去同步这个新的master。同步是一个重量及操作,它能同时给
这个client和master增加负担。这儿有一些措施,一个应用程序可以用来减轻同步的负担。

延迟client同步:

当组内有了一个新的master,不论是被应用程序指定的还是因为选举的结果,所有的clients必须去同步这个新的master。这会使新的master的资源过度损耗,因为很多clients可能都试图去和它通信和从它那儿取得记录。clients应用程序如果想延迟client的同步,应该用DB_REP_CONF_DELAYCLIENT标志去调用DB_ENV->rep_set_config 方法。这个配置使得client总从DB_ENV->rep_process_message方法返回DB_REP_NEWMASTER,但是这个client将不会继续去同步这个新的master。Client端应用程序选择延迟同步,用这种方法,那么将来再用DB_ENV->rep_sync方法去同步将是可靠的。

client-to-client的同步:

Clients可以接受和服务其他clients的请求。Clients请求记录调用这个Client应用程序的传输回调函数。可以由其他Clients满足的请求,传输函数的标志被设置成DB_REP_ANYWHERE。应用程序可以选择发送这些请求到任意client,或者忽略这个标志,而把请求发送到这个消息的环境id所指定的站点。

Client应用程序可以用不管什么算法,它们选择来负载均衡到其它clients的请求。
任何client接受到一个它不能满足的请求,都将回复给请求的client,告诉它,自己不能够提供请求的信息,而那个最初的请求者,将重新请求这个信息。另外,如果这个最初的请求没有到达发要发送给的那个目标client端,这个最初的发送请求的client也将重新请求这个信息。这这些任意一种情况下,这个重新的请求将把传输函数的标志设置成DB_REP_REREQUEST 。应用程序可能通过把这个请求进一步传递给naster来响应这个DB_REP_REREQUEST 标志(因为是被这个消息的环境id指定的),或继续把这个请求传送给另一个client。

这延迟的同步和client-to-client的同步特性允许应用程序在replication组内做负载均衡。例如,考虑到一个组内有5个站点, A, B, C, D 和 E,站点E刚刚倒掉了,站点A被选举为master。站点C 和 D 被配置成延迟同步的,当B注意到站点A是一个新master,它立即进行同步。当B完成和master的同步的时候,站点C 和 D 上的应用程序调用 DB_ENV->rep_sync 方法,使它们也进行同步。站点C 和 D (和 E, 当它完成了重新引导) 可以发送他们的请求到站点 B, 而B可以负担因为同步而产生的工作和网络流量的冲击, 使的master,站点A,有空去处理正常的应用程序工作量和由于选举而暂停的写请求。

阻塞client的操作:

Clients在处理和master的同步的时候将阻塞bdb其它的操作。默认的,许多bdb方法将阻塞,直到client同步完成,然后,这些被阻塞的方法才继续调用。
那些不能等待的Client应用程序,将更愿意立即得到一个错误返回而不是阻塞,那么就应该用DB_REP_CONF_NOWAIT 标志调用DB_ENV->rep_set_config方法。如果这个clinet现在正在同步一个master,这个配置使得bdb方法调用立即返回一个DB_REP_LOCKOUT 错误,而不是阻塞。

Clients太落伍以至于不能同步:

Clients试图去和master同步的时候可能会发现,同步是不可能的了,因为client和master 已经失去联系很久了。默认地,client和master自动的检测这个状态和执行clinet内部初始化。因为内部初始化需要传输整个数据库到clinet,这可能会发费一个相对较长的时间,可能需要clinet应用程序的数据库句柄重新被打开。
那些不能等待的应用程序,更愿意推后内部初始化直到一个更加便利的时间,或者更希望做一个热备份而不是执行内部初始化,应该用REP_CONF_NOAUTOINIT 标志来调用DB_ENV->rep_set_config方法。这个配置使得bdb返回DB_REP_JOIN_FAILURE到应用程序而不是执行内部初始化。

Client应用程序如果选择了延迟同步,这样就有责任在将来的时间和master进行同步。这可以通过关闭DB_REP_CONF_NOAUTOINIT标志和调用DB_ENV->rep_sync 方法来完成,或通过执行一个热备份。

Initializing a new site

默认地,添加一个新站点到一个replication组,只需要这个client去加入。bdb将自动从master到client给它执行内部初始化,引导这个client和master同步。尽管如此,还依赖于网络和底层结构,在一些场合下使用“热备份”在组内去初始化一个client还是比较有利的。Clients不想自动执行内部初始化应该用DB_REP_CONF_NOAUTOINIT标志调用DB_ENV->rep_set_config 方法。这个配置使得bdb返回DB_REP_JOIN_FAILURE到应用程序的DB_ENV->rep_process_message方法,而不是执行内部初始化。

为了使用热备份去初始化一个到replication组的clinet,执行下面的步骤:

做个一master环境的档案备份,就像在“数据库和日志文件档案”(Database and log file archival)中描述的那样。这个备份可以是常规的备份或一个热备份。

拷贝这个档案备份到client的一个干净的环境目录中。在client的新环境里执行灾难恢复,就像在恢复程序中描述的那样。

重新配置和重新打开这个环境作为组内的一个client成员。如果拷贝这个备份到client,相对于用db_archive公用程序或用DB_ENV->log_archive方法再造日志文件的周期来说,发费较长的时间,它可能需要抑制日志再造(reclamation),直到这个新启动的client已经追上(caught up)和应用了所有在停工期间产生的log记录。

就像任何bdb应用程序一样,当应用程序启动的时候数据库环境必须在一个一致的(consistent)状态。这是可以通过在一个线程或一个进程启动时执行恢复来最简单的确定的。这是对clients和masters来说无害的,即使它们不是严格的必需的,也就是说即使他们实际上没什么需要恢复的。

Bulk transfer

组内的站点们可能通过用DB_REP_CONF_BULK标志调用DB_ENV->rep_set_config 方法,而把配置成使用批量传输的。当被配置成批量传输,站点们将在一个缓冲区内积聚记录,然后在一次单一的网络传输中把它们传送给另一个站点。配置批量传输对master来说当然很有意义。另外,使用client-to-client同步的应用程序可能会发现,配置成批量传输对clients站点们来说也是很有帮助的。

当一个master正在产生新的log记录时,或者,或请求任何master的信息时,如果批量传输被配置,记录将堆积在一个批量缓冲区中。当缓冲区被装满了或一个永久的记录(例如,一个事务提交或一个检查点记录)被这个client排队等待,批量缓冲区将发送给client。

当一个client在响应另一个client的请求的信息的时候,如果批量传输被配置,记录将在批量缓冲区中堆积。批量缓冲区将发送给client,当缓冲区被装满了或当这个client的请求已经被满足了,再没有特别类型的记录将需要这缓冲区去发送了。
批量缓冲区的大小,它自己已经内定了不能被配置。尽管如此,在一次传输数据的总的大小可以通过使用DB_ENV->set_rep_limit方法来限制。



Transactional guarantees

在总的数据库环境的事务保证的上下文中去考虑replication是和重要的。作为简要的回顾,在一个非复制(non-replicated )中事务保证,是基于写log文件记录到稳定的存储设备上,通常是一个磁盘驱动器。如果应用程序回系统出了故障,bdb的日志信息将在恢复时被回顾,而且数据库被更新,以使已提交的事物的改变部分出现,所有未提交的而改变的部分不出现。在这种情况下,没有信息将会丢失。

如果一个数据库环境不要求当事务提交的时候把log写到稳定存储设备上(使用DB_TXN_NOSYNC标志能以牺牲事务的经久性为代价来增加性能),bdb恢复将只能把这个存储系统恢复到最后一个提交了的被保存在磁盘上了的状态。在这种情况下,信息可能已经丢失(例如,一些已经由事物提交了的改变可能在恢复之后不会出现在数据库中)。

更进一步。如果这儿有数据库或log文件丢失或腐烂(例如,如果一个磁盘驱动器出了故障),然后灾难恢复将是必要的,bdb恢复将只能把这个系统重新存储到最后一次归档log那儿。在这中情况下,信息仍然可能被丢失。


复制(Replicating)这个数据库环境通过添加一个新的组成到“稳定存储”上扩展了这个模式:这个clinet的replicated信息。如果一个数据库环境是replicated,在数据库或log丢失的情况下,这儿也不会有信息丢失,因为这个复制系统可以被配置成包含数据库和log记录直到故障点的全部的设置。一个数据库丢失了一个磁盘驱动器能使这个磁盘被复制,然后,它有能重新加入这个复制(replication)组。

由于这个新的稳定存储的组成部分,指定DB_TXN_NOSYNC到一个复制组将不再牺牲耐久性了,只要具备一个或多个clients有公认的master所发送消息的收条。因为网络连接通常比本地同步磁盘写的快,replication成为大幅度提高它们的性能和可靠性的一个方法。

应用程序发送函数的返回状态必须被应用程序设置成确保应用程序想要提供的事务保障。无论什么时候,发送函数返回失败,本地数据库环境的log将被刷新(flushed),以确保任危急到到数据库完整性的信息不被丢失。因为这个刷新是一个昂贵的开销,会影响数据库性能,如果可能的话,应用程序应该避免从发送函数那返回一个错误信息。


replication事务保障唯一感兴趣的消息类型是当应用程序的发送函数指定了DB_REP_PERMANENT 标志被调用。如果发送函数曾经返回失败这儿将是没有原因的,除非
DB_REP_PERMANENT 标志被指定--消息没有DB_REP_PERMANENT被指定,不会使数据库有明显的改变,而且发送函数可以成功返回到bdb,只要这个消息被发送到client(s),或仅仅被拷贝到本地应用程序内存中预备发送。


当一个client收到一个DB_REP_PERMANENT 消息,这个client将在返回前刷新它的log到稳定存储设备上(除非这个client环境曾经用DB_TXN_NOSYNC 选项配置过)。
如果这个client不能刷新一个全部的事务记录到磁盘,不管什么原因(例如,在被标志的消息前丢失了一个log记录),在client上调用DB_ENV->rep_process_message方法将返回DB_REP_NOTPERM 和在ret_lsnp参数中返回这个记录的LSN到应用程序。


这个应用程序的client或master消息处理的循环应该适当的带些动作以确保在这种情况下的正确的事务保障。当丢失的记录到达,而且允许随后处理这些以前存储的永久记录,在clinet上调用DB_ENV->rep_process_message 方法将返回DB_REP_ISPERM和返回永曾经被刷新到磁盘中的久记录的最大的LSN。Client 应用次序可以用这些LSN决定性的知道是否某些特定的LSN被永久存储了。


一个应用程序依赖于client的能力去成为master,而且保证没有数据曾经被丢失,将需要编写发送函数返回一个错误,无论什么时候它都不能保证将赢得下一次选举的站点会有这个记录。


应用程序不要求这个级别的事务保证将不需要让这发送函数返回失败(除非master的数据库环境用DB_TXN_NOSYNC配置过),因为任何危急到数据库完整性的信息在发送被调用前已经被刷新到本地log文件。


总的来说,发送函数要返回失败的唯一的原因是当master的数据库环境被配置成当事务提交的时候不去刷新log(也就是说,在master上DB_TXN_NOSYNC被配置了), DB_REP_PERMANENT 标志被指定给消息, 而且发送函数不能决定哪些clients收到了当前的消息(和所有在当前消息之前的消息)。多少clients在发送函数成功返回之前需要接收这个消息那是应用程序的选择(可能不是过多的依赖于特定数目的cleints报告成功作为一个或多个物理上分布式的 clients)。

如果,尽管如此,master上的应用程序确实需要在磁盘上的耐久性,那么这个应用程序应该被配置成当事务提交的时候同步的刷新记录。如果一个client没被配置成同步刷新log,也就是说,一个client运行的时候DB_TXN_NOSYNC是被被配置的,当它变成master的时候,那么它将取决于应用程序去适当地重新配置那个client。也就是说,这个应用程序必须明确的调用DB_ENV->set_flags去重新配置这个新成为master的client,使异步log刷新无效。

当然,确保replicated master和client环境确实是互相独立的很重要。例如,如果master和clients在同一个能源供给上(on the same power supply),一个client承认收到一个消息对事情是没什么帮助的,因为能源供给的失败仍然潜在地会使信息丢失。

配置的你基于replication的应用程序,能事务和性能上找到最佳结合点,是很复杂的。简言之,这儿有一些应用程序可以设置的地方以调节:为master环境指定DB_TXN_NOSYNC;为client环境指定DB_TXN_NOSYNC;不同的站点一起参加选举的那个优先权;应用程序发送函数的行为。

首先,在一个replication client中当一个事物提交的时候,写和同步刷新log几乎没什么用处。如果这些系统共享一个资源或多个系统同时出故障也许写和同步刷新log还有点用。默认地,所有的bdb环境,不管是master还是client,当事务提交的时候或预先地,都同步地刷新log。

考虑两个有网络连接的的系统。一个作为master,一个作为只读的client。如果master倒掉了client取代之,在这次故障后,master又重新加入到replication组。master 和client都被配置成当事务提交的时候不同步刷新日志(也就是说DB_TXN_NOSYNC 在两个系统上都被配置)。这个应用程序的发送函数从不返回失败到bdb库,只个简单的传递消息到这个client(或许基于一个广播机制),而且总是返回成功。在client上,由client的DB_ENV->rep_process_message方法返回的DB_REP_NOTPERM也将被忽略。这个系统配置有优秀的性能,但在某些失败的模式下有可能丢失数据。

如果这个master和client都一下子到掉了,就有可能丢失已经提交了的事务,也就是说,事务的耐久性没有被维持。有责任去提高系统的能源供给的独立性和把他们放在物理上隔离的地方。

如果这两个系统间的连接出了故障(或者仅仅是一些消息丢失了),并且随后这个master倒掉了,也有可能失去已提交的事务。又是因为事务的耐久性没有被维护。下面的一些方法中可以提高可靠性:

使用可靠的网络协议(例如,tcp而不是udp)。

增加clients和网络路径的数目,以使消息不太可能被丢失。在这种情况下,确保 client确实收到了这消息以赢得任何随后的选举也是很重要的。 如果一个client没有受到这个消息而赢得了随后的选举,那么数据仍然可能被丢失。

进一步的,系统可能想保证消息交付给了client(s)(例如,去阻止网络连接简单的丢弃消息)。一些系统可能想确保clients从来不返回已过期的信息,也就是说,一旦事务提交后在master上返回成功,将没有client在响应只读请求时返回旧的信息。下面的改变可能会用来阐述这些观点:

编写应用程序的发送函数,使它们直到一个或多个client承认收到了这个消息时才返回到bdb。这个clients的数目的选择是由应用程序决定的:你将很可能会想网络隔离(确保每个物理站点的client收到这个消息)和地理上多样性(确保一个client在每条线路“each coast ”上都收到这个消息)。


编写client的消息处理循环,使直到DB_ENV->rep_process_message返回成功的时候才承认收到这条信息。当DB_ENV->rep_process_message 方法返回DB_REP_NOTPERM 时意味着这个消息不能被刷新到client的磁盘。如果这个client不向master承认收到这个消息直到随后调用的DB_ENV->rep_process_message方法返回DB_REP_ISPERM而且这个返回的LSN至少和这个消息的LSN一样大,然后这个master的发送函数将不会返回success到bdb库。这意味着,直到那些经由挑选的clients已经收到了这个消息而且认为完成了,mastet上正在提交事务的这个线程将才被允许继续下去。

作为选择,client的消息处理循环可以向master承认收到了这个消息,但是用一个错误代码指明那个应用程序的发送函数不要返回到bdb库,直到一个随后的来自同一个client的确认成功。

应用程序的发送回调函数被bdb调用包括一个记录的LSN被发送(如果对那个记录来说是适当的)。当DB_ENV->rep_process_message 返回指示一个永久的记录已经被写入,然后它也回返回这个被写入的永久记录的最大LSN 。


这儿最后的两关需要考虑。首先,当应用程序的发送函数被调用的后,事务是不可被中途中断的,因为这个 master可能已经把事物提交日志记录写入磁盘,所以中途中断将不再是一个可选择项。第二,一个相近的问题是,如果发送函数返回失败,尽管这个master将试图去刷新本地log,这个刷新操作将可能失败(例如,当本地磁盘是满的)。此外,事务不能被中途中断,因为一个或多个clients可能已经提交了这个事务即使发送函数返回失败。杰出的应用程序可能也忍受不了这些不太可能的失败方式。在那中情况下应用程序可能想:

1,配置这master总去同步本地提交的事务(关闭DB_TXN_NOSYNC 配置项)。这样将对性能有很大的影响,当然(使用replication的其中的一个原因是避免本地磁盘的写操作),在这种配置下,不管什么情况,写本地日志失败将使事务中途中断。



2,在任何情况下都不要从应用程序的发送函数中返回,除非挑选的那些client已经承认了收到那个消息。直到这个发送函数返回到这个bdb库,master上这个正在提交事务的线程都将等待,所以没有应用程序能表现出承认事务已经被提交了。


最后可供牵扯到这些类型的失败的应用程序选择的是使用分布式事务,保证完全的一致性实现全局的事务管理和垮过多bdb环境履行两阶段提交。更多的了解这个可以参见分“the Distributed Transactions”那一章。
分享到:
评论

相关推荐

    Berkeley DB参考手册PDF版本

    DB Replication(HA)中部 - **12.1 Synchronizing with a master** - **与主节点同步**:说明从节点如何与主节点保持数据的一致性。 - **12.2 Initializing a new site** - **新站点初始化**:介绍如何在复制...

    Berkeley DB参考资料

    DB Replication (HA)中部 - **12.1 Synchronizing with a master** - **同步过程**:如何与主节点保持数据同步。 - **12.2 Initializing a new site** - **初始化新站点**:初始化新站点以加入复制集群的过程。...

    Berkeley_DB_参考手册

    DB Replication (HA) 续 - **12.1 Synchronizing with a master**:与主节点同步数据的方法。 - **12.2 Initializing a new site**:初始化新站点的过程。 - **12.3 Bulk transfer**:大批量数据传输技术。 - **...

    安川MP7系列工控系统源码解析:关键算法与硬件交互揭秘

    内容概要:本文深入剖析了安川MP7系列工业控制系统的关键源码,重点介绍了运动轨迹规划、通信协议处理以及故障处理机制等方面的技术细节。通过对实际代码片段的解读,揭示了该系统在硬件寄存器直接访问、特殊功能码处理等方面的独特之处。同时,文中还分享了一些基于实践经验得出的重要参数设置及其背后的故事,如特定摩擦补偿系数的选择原因等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对安川产品有一定了解并希望深入了解其内部工作机制的专业人士。 使用场景及目标:帮助读者掌握安川MP7系列控制器的工作原理,提高对类似系统的维护能力和故障排查效率。对于想要进一步研究或二次开发该系统的开发者来说,也能提供宝贵的参考资料。 其他说明:文章不仅限于理论讲解,还包括了许多来自一线的实际案例和经验教训,使读者能够更好地理解和应用所学知识。

    自动化测试与脚本开发_Python3_pynput_键盘鼠标操作录制执行代码生成工具_用于自动化测试_脚本录制_重复操作模拟_宏命令生成_提高工作效率_支持GUI界面_跨平台兼容_.zip

    自动化测试与脚本开发_Python3_pynput_键盘鼠标操作录制执行代码生成工具_用于自动化测试_脚本录制_重复操作模拟_宏命令生成_提高工作效率_支持GUI界面_跨平台兼容_

    嵌入式八股文面试题库资料知识宝典-深入分析Windows和Linux动态库应用异同.zip

    嵌入式八股文面试题库资料知识宝典-深入分析Windows和Linux动态库应用异同.zip

    嵌入式八股文面试题库资料知识宝典-C语言总结.zip

    嵌入式八股文面试题库资料知识宝典-C语言总结.zip

    风储直流微电网母线电压控制策略与双闭环MPPT技术研究

    内容概要:本文详细探讨了风储直流微电网中母线电压控制的关键技术。首先介绍了风储直流微电网的背景和发展现状,强调了母线电压控制的重要性。接着阐述了永磁风机储能并网技术,解释了永磁风机如何通过直接驱动发电机将风能转化为电能,并确保与电网的同步性和稳定性。然后深入讨论了双闭环控制MPPT技术,这是一种通过内外两个闭环控制系统来实现实时调整发电机运行参数的技术,确保风机始终处于最大功率点附近。最后,文章探讨了储能控制母线电压平衡的方法,即通过储能系统的充放电操作来维持母线电压的稳定。结论部分指出,通过这些技术的有机结合,可以实现对风储直流微电网的有效管理和优化控制。 适合人群:从事新能源技术研发的专业人士、电气工程研究人员、风电系统工程师。 使用场景及目标:适用于希望深入了解风储直流微电网母线电压控制策略的研究人员和技术人员,旨在帮助他们掌握最新的控制技术和方法,以提高系统的稳定性和效率。 其他说明:文章还对未来风储直流微电网的发展进行了展望,指出了智能化和自动化的趋势,以及储能技术的进步对系统性能的影响。

    嵌入式八股文面试题库资料知识宝典-C++object-oriented.zip

    嵌入式八股文面试题库资料知识宝典-C++object-oriented.zip

    【操作系统开发】HarmonyOS目录结构详解:构建高效开发环境与跨设备协同应用

    内容概要:文章详细介绍了HarmonyOS的目录结构及其重要性,从整体框架到核心目录的具体功能进行了全面剖析。HarmonyOS凭借其分布式架构和跨设备协同能力迅速崛起,成为全球操作系统领域的重要力量。文章首先概述了HarmonyOS的背景和发展现状,强调了目录结构对开发的重要性。接着,具体介绍了根目录文件、AppScope、entry和oh_modules等核心目录的功能和作用。例如,AppScope作为全局资源配置中心,存放应用级的配置文件和公共资源;entry目录是应用的核心入口,负责源代码和界面开发。此外,文章还对比了HarmonyOS与Android、iOS目录结构的异同,突出了HarmonyOS的独特优势。最后,通过旅游应用和电商应用的实际案例,展示了HarmonyOS目录结构在资源管理和代码组织方面的应用效果。; 适合人群:具备一定编程基础,尤其是对移动操作系统开发感兴趣的开发者,包括初学者和有一定经验的研发人员。; 使用场景及目标:①帮助开发者快速理解HarmonyOS的目录结构,提高开发效率;②为跨设备应用开发提供理论和技术支持;③通过实际案例学习资源管理和代码组织的最佳实践。; 其他说明:HarmonyOS的目录结构设计简洁明了,模块职责划分明确,有助于开发者更好地管理和组织代码和资源。随着万物互联时代的到来,HarmonyOS有望在开发便利性和生态建设方面取得更大进展,吸引更多开发者加入其生态系统。

    飞轮储能充放电控制Simulink仿真模型:基于永磁同步电机的矢量控制与dq轴解耦

    内容概要:本文详细介绍了飞轮储能充放电控制的Simulink仿真模型,重点在于采用永磁同步电机的矢量控制和dq轴解耦控制策略。充电时,外环控制转速,内环控制dq轴电流;放电时,外环控制直流母线电压,内环同样控制dq轴电流。文中还讨论了硬件与软件环境的选择,以及仿真模型的调试与运行情况,最终得出该模型具有良好的跟随性能和波形完美度。 适用人群:从事电力电子系统、储能技术和Simulink仿真的研究人员和技术人员。 使用场景及目标:适用于需要对飞轮储能系统进行深入研究和仿真的场合,旨在提高充放电效率和稳定性,满足不同应用场景的需求。 其他说明:该仿真模型已调试完成,可以直接用于进一步的研究和实际应用,为未来的飞轮储能技术研发提供了有价值的参考。

    嵌入式八股文面试题库资料知识宝典-北京瑞德方科技.zip

    嵌入式八股文面试题库资料知识宝典-北京瑞德方科技.zip

    嵌入式八股文面试题库资料知识宝典-同方万维硬件测试工程师.zip

    嵌入式八股文面试题库资料知识宝典-同方万维硬件测试工程师.zip

    1_15套python PDF格式.zip

    1_15套python PDF格式.zip

    三相三电平整流器仿真:基于电压电流双闭环控制与SPWM调制的性能分析

    内容概要:本文详细介绍了三相三电平整流器的仿真过程及其性能分析。文中首先概述了三相三电平整流器的基本概念及其在电力系统中的重要作用,接着重点探讨了电压电流双闭环控制方式的工作原理和优势,以及SPWM调制技术的具体应用。通过仿真文件展示了整流器在不同条件下的响应情况,验证了这两种技术的有效性和优越性。最后,作者表达了对未来实际应用的期望。 适合人群:从事电力电子研究的技术人员、高校相关专业师生、对电力控制系统感兴趣的工程爱好者。 使用场景及目标:适用于希望深入了解三相三电平整流器工作原理和技术细节的研究人员;目标是在理论基础上掌握电压电流双闭环控制和SPWM调制的实际应用方法。 其他说明:本文提供的仅为仿真文件,未涉及实物实验数据。

    嵌入式八股文面试题库资料知识宝典-恒光科技.zip

    嵌入式八股文面试题库资料知识宝典-恒光科技.zip

    嵌入式八股文面试题库资料知识宝典-北京天华威视科技有限公司面试题.zip

    嵌入式八股文面试题库资料知识宝典-北京天华威视科技有限公司面试题.zip

    嵌入式八股文面试题库资料知识宝典-微软研究院笔试题目的答案.zip

    嵌入式八股文面试题库资料知识宝典-微软研究院笔试题目的答案.zip

    Arduino UART实验例程【正点原子EPS32S3】

    Arduino UART实验例程,开发板:正点原子EPS32S3,本人主页有详细实验说明可供参考。

    嵌入式八股文面试题库资料知识宝典-朝歌数码.zip

    嵌入式八股文面试题库资料知识宝典-朝歌数码.zip

Global site tag (gtag.js) - Google Analytics