u012559967的专栏

道德，是为了群体的繁衍，最后促进个体的生存、繁衍，大家共同达成“社会契约”。道德，往往是反人性的。罗曼·罗兰：“这个世界上，只有一种真正的英雄主义，那就是认清了生活的真相后还依然热爱它。菲兹杰拉德：“同时持有全然相反的两种观念，还能正常行事，是第一流智慧的标志。一件事情出现不好的结果时，责怪、埋怨、后悔都是无用的，它们改变不了结果。在人生中，博弈是第三层智慧，定力是第二层智慧，选择是第一层智慧。如何博弈，如何保持定力，如何做出选择，都决定着人生的走向。法律，是道德的子集，是维护群体存在的道德底线。

无论你遵守与否，大自然的法则是无法改变的，你若无视“重力法则”，从屋顶跳下，那给你善后的就不是“重力警察”了。同理，如果你不遵循成长法则，也不会有“成长警察”找你麻烦，你只会发现自己的成长不再那么顺利了而已。承诺：能使你下决心投入这个大事物、大事件之中，因为你看到了其他人、其他事物所做的贡献的价值。或将它们当做接口，或将它们当做学习的原材料，或者驱动自己去吸取其中的经验教训。谦逊：能使你将自己视为周围世界里独特的一份子，但不是最重要的那个。你无法控制他人的赞誉，但你能把握自己的表现。

在CSDN等平台中可使用Mermaid来绘制思维导图。那么先简单介绍下Mermaid。Mermaid是一个用于画思维导图、流程图、状态图、时序图、甘特图等图的工具，使用 JavaScript 进行本地渲染。虽然Mermaid暂不支持思维导图的绘制，但是可通过绘制流程图来替代简单的思维导图。

linux安装配置mysql的方法主要有yum安装和配置安装两种，由于yum安装比较简单，但是会将文件分散到不同的目录结构下面，配置起来比较麻烦，这里主要研究一下配置安装mysql的方法。

在安装完centos系统以后，系统的分区大小往往不是自己预期的大小，这个时候就需要我们自己手动来调整分区大小，在centos7 里面，手动调整分区大小的方法如下。

最近在编译mediasoup-demo-v3的时候，要用到python3.7以上的版本，但是本地yum用到了phthon2.7，强行升级会导致yum的不可用，本文记录在不影响python2的情况下，升级使用python3的方法。我这里安装的是3.7.4版本，如果需要其他的版本，找到对应的下载链接即可。

cent os7服务器使用nvm安装的node之后，只要使用npm或者node，均会出现以下问题。

微服务架构设计的中心思想是将服务进行拆分，但是在这个过程中，如果被依赖的服务发生奔溃，就会引起一系列问题。为了解决这个问题，就会引入重试的机制，重试又会引入幂等性的问题，下面我们就分析这个过程，然后探讨一下常见的解决方案。

上篇文章《》记录了RocketMQ的一些基本的概念，本文主要写几个go语言操作RocketMQ的示例代码。

事务消息：云消息队列 RocketMQ 版提供类似XA或Open XA的分布式事务功能，通过云消息队列 RocketMQ 版事务消息能达到分布式事务的最终一致。半事务消息：暂不能投递的消息，生产者已经成功地将消息发送到了云消息队列 RocketMQ 版服务端，但是云消息队列 RocketMQ 版服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。

系列目录：《分布式事务（一）—— 事务的基本概念》《分布式事务（二）—— CAP和Base理论》《分布式事务（三）—— 两阶段提交解决方案（2PC）》《分布式事务（四）——TCC补偿模式解决方案》《分布式事务（五）——基于本地消息和可靠消息的解决方案》  最大努力通知也是一种解决分布式事务的方案，其主要是用于解决执行结果的回调通知问题，尤其是执行结果是一个外部调用，我们没法干预其执行的时候，执行结果如何通知给我们的场景。比如我们系统中调用支付宝的支付接口，支付是否成功我们肯定是要关注的，支付宝如何将执行结果

系列目录：《分布式事务（一）—— 事务的基本概念》《分布式事务（二）—— CAP和Base理论》《分布式事务（三）—— 两阶段提交解决方案（2PC）》《分布式事务（四）——TCC补偿模式解决方案》  基于本地消息表实现数据一致性的方案最初是由eBay提出的，此方案的核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定势任务将消息发送到消息中间件，待确认消息发送给消费方成功再将定时任务的消息删除。这种方式的主要逻辑就是通过定势任务一致发送消息，直到成功为止。其优缺点也就一目了然了，最大的问题也就是在定

首先需要选择某种TCC分布式事务框架，各个服务力就会有这个TCC分布式事务框架在运行然后你原本的一个接口，需要改造成3个逻辑： Try-Confirm-Cancel先是服务调用链路依次执行Try逻辑如果都正常的话，TCC分布式事务框架推进执行Confirm逻辑，完成整个事务如果某个服务的Try逻辑有问题，TCC分布式事务框架感知到之后会推进执行各个服务的Cancel逻辑，插销之前执行的各个操作先来Try一下，不要把业务逻辑完成，先试试，看各个服务能不能正常运转，能不能先冻结需要的资源。

系列目录：《分布式事务（一）—— 事务的基本概念》《分布式事务（二）—— CAP和Base理论》  两阶段提交方案在目前的分布式事务中只是一种方案，因为其比较复杂，且问题比较多，实际使用的比较少，但是我们也可以进行了解。  2PC是一个非常典型的中心化原子提交协议：这里所说的中心化指协议中有两类节点，一个是中心化的协调节点(Coordinator)和N个参与者节点(Partcipant).两个阶段指的是：  两阶段提交的设计思路就是在N个调用的节点的上面加上一个协调的节点。在发生事务操作的时候，先让协调节点

总体来说，Base理论面向的是大型高可用可扩展的系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致模型，而是牺牲强一致来获得可用性，并允许数据在一段时间内不一致，但最终达到一致状态。同时，在实际的分布式场景中，不同业务单元和组建对数据一致性的要求不同，因此在具体的分布式系统架构设计的过程中ACID特性和Base理论往往又会结合在一起。软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点数据副本之间进行数据同步的时候可以存在延时。

一组sql语句操作单元，组内所有的sql语句完成一个完成的业务，如果整组成功，意味着全部sql都执行成功，如果其中任何一个失败，意味着整个操作都失败。失败，意味着整个过程都没有意义，应该让数据库回到操作前的初始状态，这种特性，就叫做事务。

在实际的代码中，在main.cpp 中调用mediasoup_worker_run函数在mediasoup_worker_run函数实现中进行了各个模块的初始化。

我们知道，在mediasoup库中，有js和c++的两个进程，在顶层的mediasoup-demo中会创建多个Worker来创建对个进程，所以就会出现一个js进程对应多个c++子进程的情况，那这些进程中间是如何通信的呢？

Mediasoup是由两部分组成的，一部分是js的控制模块，一部分是c++的传输模块，在这里我们用mediasoup demo的代码开始，分析整个进程的启动过程。

Mediasoup C++核心类图Mediasoup 完整类图