13518219792
MySQL 8.0.16 已经发布，它像往常一样增强了组复制 Group Replication 功能。
公司主营业务：成都网站设计、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出天元免费做网站回馈大家。
这篇文章介绍了 MySQL 8.0.16 为 Group Replication 带来的新功能：
Message fragmentation（信息碎片化）。
背景
Group Replication 目前使用 XCom（一种组通信引擎），特点：原子性，组员状态检测等。每个成员的组复制插件先将信息转发到本地 XCom，再由 XCom 最终以相同的顺序将信息传递给每个组成员的 Group Replication 插件。
XCom 由单线程实现。当一些成员广播信息过大时，XCom 线程必须花费更多的时间来处理那个大信息。如果成员的 XCom 线程忙于处理大信息的时间过长，它可能会去查看其他成员的 XCom 实例。例如，忙碌的成员失效。如果是这样，该组可以从该组中驱逐忙碌的成员。
MySQL 8.0.13 新增 group_replication_member_expel_timeout 系统变量，您可以通过它来调整将成员从组中驱逐的时间。例如，怀疑成员失败，但成员实际上忙于处理大信息，给成员足够的时间来完成处理。在这种情况下，是否为成员增加驱逐超时的设置是一种权衡。有可能等了很久，该成员实际真的失效了。
Message fragmentation（信息碎片化）
MySQL 8.0.16 的 Group Replication 插件新增用来处理大信息的功能：信息碎片化。
简而言之，您可以为成员的广播信息指定最大值。超过最大值的信息将分段为较小的块传播。
您可以使用 group_replication_communication_max_message_size 系统变量指定允许的信息最大值（默认值为10 MiB）。
示例
让我们用一个例子来解释新功能。图1显示了当绿色成员向组广播信息时，新功能是如何处理的。
图1 对传出信息进行分段
1. 如果信息大小超过用户允许的最大值（group_replication_communication_max_message_size），则该成员会将信息分段为不超过最大值的块。
2. 该成员将每个块广播到该组，即将每个块单独转发到XCom。
XCom 最终将这些块提供给组成员。下面三张图展示出了中间绿色成员发送大信息时工作的新特征。
图2a 重新组合传入的信息：第一个片段
3. 成员得出结论，传入的信息实际上是一个更大信息的片段。
4. 成员缓冲传入的片段，因为他们认为片段是仍然不完整的信息的一部分。（片段包含必要的元数据以达到这个结论。）
图2b 重新组合传入的信息：第二个片段
5. 见上面的第3步。
6. 见上面的第4步。
图2c 重新组合传入的信息：最后一个片段
7. 成员得出结论，传入的信息实际上是一个更大信息的片段。
8. 成员得出结论，传入的片段是最后一个缺失的块，重新组合原始信息，然后对其进行处理，传输完毕。
结论
MySQL 8.0.16 已经发布后，组复制现在可以确保组内交换的信息大小不超过用户定义的阈值。这可以防止组内误判而驱逐成员。
我觉得这个没有太大的可比性..
数据库的选择还是按照程序来比较好。
一般的话.. PHP和MySQL是一对（它们都开源，而且效果非常好）..
如果你开发一个几乎不怎么用到数据库的程序，那么你会怎样？我会选择使用文本的方式记录数据
如果开发一个比较小型的程序，我就会选择使用MySQL...
如果需要开发一个大型的程序，那么就可以选择ORACLE等大型数据库了...（按照我个人的..我还是会选择MySQL）
不用考虑太多效率问题，你真正需要把数据库效率都算上的时候，我相信你服务器上运行不仅仅是php+apache了，你肯定还会运行很多其他的缓存程序...
至于说win平台，如果你做开发不建议使用win平台，一个是不稳定，再一个它对PHP的支持性也不是非常好（很多函数没法用）
另外就说实验了，如果你不是精通这些，那么建议你选择MySQL，因为选择MySQL作为PHP数据库的人相当多.. 找一些MSSQL或者ORACLE的.. 太难了...
最后说一下，上面我说的似乎对你的问题没有作用..我只是想说对于这个性能问题..还是得先看网站的类型。你一个非常小的网站去用ORACLE当然是不划算的..
实际上有一个非常简单的办法，你可以利用数据库操作的原子性来实现，不需要那么复杂的锁机制，甚至队列。就按你的方法来，假设任务数据表 task 里有两个字段 id, status，我们定义status三个状态
0: 待处理1: 正在处理2: 处理完成
假设你有一堆 PHP 进程都用如下 SQL 语句去取出数据库里的待处理任务
SELECT * FROM task WHERE status = 0
取出来以后，我们为了防止其他用户不再重复取出要把它的状态标记为 1
UPDATE task SET status = 1 WHERE id = xxx
但是等等，这样就会产生如你所说的资源抢夺，但如果加上一个简单的技巧就可以避免，你把语句变成这样
UPDATE task SET status = 1 WHERE id = xxx AND status = 0
熟悉一点数据库的人可能会说这样还是避免不了抢夺，只是避免了重复写入。
我要说的是，能避免重复写入就够了，我们的进程在执行完这条操作后，去获取 affected_rows ，即更新的条数，根据数据库的原子性，只有第一个抢占的进程才会返回 1，它可以进行后面的操作。而剩下返回 0 的进程，直接进入下一个等待流程即可。
这个问题的有趣之处，不在于问题本身（“原子性、一致性的实现机制是什么”），而在于回答者的分歧反映出来的另外一个问题：原子性和一致性之间的关系是什么？
我特别关注了@我练功发自真心
的答案，他正确地指出了，为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制。但这个答案仍然是不完整的，因为原子性并不能够完全保证一致性。
按照我个人的理解，在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。
首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。
在
数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在
同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即
在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。
为了实现原子性，需要通过日志：将所有对
数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已
经执行成功的操作撤销，从而达到“全部操作失败”的目的。最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crash
recovery的过程：读取日志进行REDO（重演将所有已经执行成功但尚未写入到磁盘的操作，保证持久性），再对所有到崩溃时尚未成功提交的事务进行
UNDO（撤销所有执行了一部分但尚未提交的操作，保证原子性）。crash
recovery结束后，数据库恢复到一致性状态，可以继续被使用。
日志的管理和重演是数据库实现中最复杂的部分之一。如果涉及到并行处理和分布式系统（日志的复制和重演是数据库高可用性的基础），会比上述场景还要复杂得多。
但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果。例如，事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上100。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了100元。那么最后的结果应该是A增加了200元。但事实上，
事务1最终完成后，帐号A只增加了100元，因为事务2的修改结果被事务1覆盖掉了。
为了保证并发情况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。怎样实现隔离性，已经有很多人回答过了，原则上无非是两种类型的锁：
一
种是悲观锁，即当前事务将所有涉及操作的对象加锁，操作完成后释放给其它对象使用。为了尽可能提高性能，发明了各种粒度（数据库级/表级/行级……）/各
种性质（共享锁/排他锁/共享意向锁/排他意向锁/共享排他意向锁……）的锁。为了解决死锁问题，又发明了两阶段锁协议/死锁检测等一系列的技术。
一种是乐观锁，即不同的事务可以同时看到同一对象（一般是数据行）的不同历史版本。如果有两个事务同时修改了同一数据行，那么在较晚的事务提交时进行冲突
检测。实现也有两种，一种是通过日志UNDO的方式来获取数据行的历史版本，一种是简单地在内存中保存同一数据行的多个历史版本，通过时间戳来区分。
锁也是数据库实现中最复杂的部分之一。同样，如果涉及到分布式系统（分布式锁和两阶段提交是分布式事务的基础），会比上述场景还要复杂得多。
@
我练功发自真心
提到，其他回答者说的其实是操作系统对atomic的理解，即并发控制。我不能完全同意这一点。数据库有自己的并发控制和锁问题，虽然在原理上和操作系统
中的概念非常类似，但是并不是同一个层次上的东西。数据库中的锁，在粒度/类型/实现方式上和操作系统中的锁都完全不同。操作系统中的锁，在数据库实现中
称为latch（一般译为闩）。其他回答者回答的其实是“在并行事务处理的情况下怎样保证数据的一致性”。
最后回到原来的问题（“原子性、一致性的实现机制是什么”）。我手头有本Database
System
Concepts（4ed，有点老了），在第15章的开头简明地介绍了ACID的概念及其关系。如果你想从概念上了解其实现，把这本书的相关章节读完应该能大概明白。如果你想从实践上了解其实现，可以找innodb这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对操作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。
