IcyFenix
IcyFenix
> 拜读中，受益匪浅。这句【由于主动分发通常需要源站、CDN 服务双方提供程序 API 接层面的配合，所以它对源站并不是透明的】。其中【 API 接层面】是不是【API 接口层面】？ 感谢，已更正
> @yanyuyouyou > >分离数据平面与控制平面的实质是将“程序”与“网络”进行解藕，将网络可能出现的问题（譬如中断后重试、降级）... > >在“数据平面”和“控制平面”这两个小节里，笔者会延续服务网格将“程序”与“网络”解藕的思路... > > 这些“解藕”能让我吃两碗米饭~~~ 不好意思，让你长胖了，哈哈
> 我其实是想说这个错别字的问题，作为严谨的程序员咱是不是考虑改改？ 我有看到，等下次更新会改过来。
> @UUNNFLY > 周老师，在之前您说过“通过网络进行分布式运算的八宗罪”，服务网格虽好，但没法解决诸如“带宽是无限的”，“延迟是不存在的”之类的问题，您对远程通信的透明性怎么看？ 那时候说的透明是对“功能”和“性能”都透明。 现在ServiceMesh追求的透明仅仅对“功能”透明，对“性能”不透明。
@lxiaocode > 1. Repeatable Read会对数据加写锁和读锁，意思是数据会同时加两把锁吗？ 可重复读对事务所涉及到的数据加读锁和写锁，且一直持有至事务结束，但不再加范围锁 > 2. Read Committed加了写锁为什么其他事务还可以将“90元改为110元”，难道不会阻塞写操作吗？ 例子举得确有问题，将90元改成110元是会被阻塞的。正确的举例应该是“将110元改成90元”或者“新增了一本90元的书”。这会导致事务中相同的两条查询返回不同的结果，即不可重复读问题。 > 3. Read Uncommitted加了写锁其他事务应该只能看到未提交的数据，为什么会购买到“90元的书”？ 不是只能看到未提交数据，而是**可以**看到未提交数据，为什么可以看到未提交事务中的数据，在文中专门加了括号说明——禁止施加读锁不等同于禁止读取数据。 > 4. 我在查看MySQL参考文档时看到 REPEATABLE READ对于范围查询会加间隙锁防止其他事务在该范围内插入数据，这与文中所说的Repeatable Read有差异。 > 5. 同样，MySQL参考文档说READ COMMITTED才会发生幻读，与文中所说的也不符。一时之间，不知道谁对谁错，把我看懵了，希望大佬解答我的疑惑。 应避免混淆数据库理论与具体数据库实现，避免混淆ANSI/ISO SQL-92标准与MySQL/InnoDB两者的关系， 这篇文章是针对ANSI/ISO SQL-92去写的，不局限于某一种数据库。由于实现机制的差异，不同数据库采用不同的默认隔离级别，或相同隔离级别下的细节表现存在差异都是可以接受的。...
@lxiaocode > “对事务涉及到的数据加的写锁会一直持续到事务结束，但加的读锁在查询操作完成后就马上会释放” 是，当作为“读者”时对数据加读锁，查询完成后释放读锁，即使事务还没提交，此时数据既没有读锁也没有写锁，所以其他事务可以施加写锁，对该数据进行修改导致“不可重复读问题” 的意思吗？ 并不是这样的，已经写明了“对事务涉及到的数据加的写锁会一直持续到事务结束”，RC级别中只要事务涉及到数据，直至事务之前都会有持续性的写锁，不存在“此时数据既没有读锁也没有写锁”的情况。如果事务中用到的数据没有加写锁就会造成脏写问题。 我在正文中将每一个例子都增加了一段额外的描述，请重新阅读一遍几种隔离级别的例子，希望能解答你的疑问。
@lxiaocode > 我认为的是，在RC级别中，在查询操作才会施加读锁并且在查询结束后就会立即释放，在写入操作才会施加写锁并且持续到事务结束。 确实如此，只读事务中不会有写锁。 我上一条回复的内容“RC级别中只要事务涉及到数据，直至事务之前都会有持续性的写锁”并不正确，感谢指正。
> @dengchaoh > “每一个节点收到消息后，如果这个消息是它之前没有收到过的”。 > > 周大哥，判断消息是否收到过，如果是框架统一处理，是不是得记录已处理过消息的标识，或者消息标识是有规律的，可以从某个消息确定已处理过消息的范围？ > 我考虑第二种是不可行，那就是需要记录处理过消息的标识。已处理过的消息会越来越多，而节点不能确定哪些消息是全网接收过的，无法做出清理，这样这些数据就会无限堆积，这个问题怎么处理呢？ > > 我还想到另外一种可能性，消息是否处理过，不是通过消息的标识来判断，而是识别消息的内容，跟节点已有的数据去比较。能识别消息内容的话，那就是要绑定具体业务，业务去识别。 > > 周大哥，请问是哪一种呢？我觉得是绑定具体业务的可能性更大。 这个问题是与具体实现相关的，但是一般是不需要一直存储着收到过的消息的，对于每一个节点来说，只要该消息是来源于或发送至这个节点所有的相邻节点之后，它就可以安全丢弃了——因为所有相邻节点都知道了这条消息，而且它们还知道你已经知道了这条消息。 所以，消息存储消耗取决于相邻节点的数量，而一个节点的相邻节点数量是有限的，因此一般消息不会造成太大负担。从实现上看，绝大多数Gossip Agent都不需要一个专门的数据库来支持运作，将消息hold在内存中即可，这点也从侧面说明了消息的存储压力并不大。
> @UUNNFLY > 周老师能不能加一篇对中台的介绍 好，明年合适的时候写一篇