我看没有类似的笔记软件有格式刷的，如果有的话，你记得告诉我一声

其实我觉得这些东西不是审美风格问题，而是放的位置不太符合优秀交互方案，很多按键或者组件就是勉强堆在一起了，没有做很好的循序渐进或者分类

需要一个监听主，否则每个客户端即使拉取同一份数据，由于自己的数据不是都一样的，里面最后就会各有各的保留决策，如果有一个监听主，或者决策主，就好多了

组合一下就行了，一步到位难就打组合拳，jq 提取顶层数据，或用 deepmerge 处理嵌套合并，再结合自定义脚本进一步处理块移动和深度解析，例如顺序重排和解析层数。

但是我有点疲于探讨到底有什么方案和能不能实现了，因为我一开始想表达的只是，这些都会加剧逻辑复杂度，坑也会越来越多，在我们的客户端本来就不能同时并发和及时互相沟通的情况下，性能可能会不升反降。

只要嵌套深度不发生改变，你需要考虑的就只有当前内容对比，不需要考虑内容是从哪里来的，到哪里去了。

如果嵌套深度发生改变，我们也有其他的手段，例如，就像我刚才说的，对于超级块套娃嵌套的取消，我们只关注它最顶层的所有内容，不用非要一次性解析到它最深处。

其实我觉得无法很好的单线展示差异这个坑是超级块埋下来的，因为它使得思源的 json 拥有了向下无限嵌套的可能性，，，但是我们依然可以继续上手段，只做为文档做一次顶层平行解析，超级块或者其他什么乱七八糟的嵌套都只当做一行，然后提供手动调整平行解析深度的选项，如果想更细粒度的“diff”，就增加深度。

但是还是我说的，方案永远用不完，逻辑可以无限复杂，坑也会越来越多

你说的可能是盲合并？但是思源的 json 是有迹可循的啊，远远用不到 AST-patch，自动合并 JSON 并非完全不现实。许多工具和库（例如 jq、jsonmerge、deepmerge）可以合并 JSON 数据。它们可以按照预定义的规则来合并思源块结构，尽管可能不是处理所有情况的万能方案，但对于多数常见场景，尤其是思源的规则较少的情况，完全可行。

但是逻辑上还是会越来越复杂，坑越来越多。

我再插一句，实际上并不只是多端修改同一个文件会导致这样的问题，我亲身测试，甲设备修改 A 文档，乙设备修改 B 文档，然后甲点击同步，甲同步完成之后，乙点击同步，如果乙没有同步完成，甲上线开始打开 B 文档，开始编辑修改，同时乙同步完成了，触发甲的同步，思源目前会直接拿乙修改的 B 覆盖甲的 B，导致编辑内容丢失，且是瞬间发生的，不会有数据快照，如果乙同步完了，甲上线开始打开 B 文档，开始编辑修改，然后点击同步，会直接触发冲突，可怕的是，我们甚至没有在同一时间编辑同一个文档，甚至是在编辑完成之后点击的同步

这是其中一个悖论，也就是文章中提到的一个本质上无关技术的逻辑问题，而要解决这个逻辑问题，你需要更加复杂的技术去勉强解决

我插一句，思源的笔记对于 git 来说一样是纯文本，因为.sy 本质上是 json 而已，就像 git 提交普通的程序代码一样，但是，压缩后的.sy 里面的 json 没有换行，只有一整行，也就是说 git 做不到想 diff 代码文件一样一行一行的显示冲突，但是也不是没有办法细粒度的对比差异，可以直接解析 json 来进行细粒度的对比，我估计性能开销会不小，目前思源也暂时还没有这么做，这个就属于逻辑越来越复杂，坑越来越多的情况，表示理解

牛逼 🐂

非常赞同，这种情况确实不可避免的发生，不同的是中心化服务器在面对各种请求处理时，相比 S3，总可以通过更为简单的逻辑来进行快速且实时的操作来解决问题，随之而来的就是成本增加，开发成本与设备成本权衡之下，我现在还是比较认同思源的同步机制的。

不行了睡了，顶不住了，明日再议了

另外我刚刚为了再验证一下，用 Python 做了监听，确实其实平常不会有太多文件发生改变，基本上修改哪个就只改变相关的几个文件，三到四个左右。如果每次只同步这几个文件，然后附件走进度条上传，我相信大多数人是愿意等，也容易理解的，现在，就是什么都还没有改变，只能自己在社区里自嗨一下了。

所以现在的问题是，同步的过程切割了太多不必要的小文件吗？平常编辑 sy 也很慢，或许因为这个？那我觉得附件可以走另一个通道，当他只是一个附件时，总有好的解决方法，常见的是走另外上传，显示上传进度条，而不是和 sy 这种小型文件放在一起进行多余的操作

或者说，到底什么情况下，需要打这么多的块文件？数据回滚吗？

但是这不是同步机制的问题。

可能我觉得数据结构和同步机制也有关系？话说这种结构不就是为了同步而生的吗？本地使用，软件读取明文，备份也是直接 copy 目录或者导出 sy.zip，我可能理解不到，客户端读取数据是基于这种数据结构的？

在这里的语境中，我指的是建立快照时，产生的数据分块，

那我是理解错了，我以为是 sy 里面的块结构，但是好在，你说的很多数据库会产生，我也做了假设

运行时文件是指与文档本身无关的数据库和索引
中间件处理对接是指监听 api 和文件变动对象
很多数据发生了改变是指你说的我打几个字 net 里会有一堆调用内核 api 的情况

而且假设你说的也对，我打几个字就是会产生很多小碎片，如果说，用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块，这个作为一个个人使用的本地软件，不是一种冗余吗？要怪在用户不了解的头上吗？

我不明白你提到“块”这个概念是为什么，首先，索引不会校验“块”而是文件，根本没深入到这个数据结构，“块”的改动只是触发扫盘索引而已，我自己 win 下用 bat 写个监听，日常使用中，根本没有几个文件会发生改变，而是几个文件在“高频”改变，这些文件本来就是运行时文件，而思源不通过中间件处理对接，反而放在了同步里面，内核我也看，很多数据发生了改变=很多文件发生了改变？

我想向你描述的很清楚了，包括你现在又说伺服，我一开头表达的很清楚

同步目前最简单粗暴的增本增效的方法就是，直接在服务器上给每个订阅用户运行自己的思源内核实例，在使用官方同步的情况下，客户端后端直接与云端内核通信，离线状态下客户端自己记录距离上一次同步的离线时间戳，每当与云端内核连接，就开始对比数据新鲜度，而冲突解调在云端内核进行

代表我不是不知道伺服可以最快解决，但是你不能作为一个官方订阅，让用户自己伺服吧，所以我直接说了云内核，增本增效。

但是说实话，就做一个最简单的同步，单纯从打开窗口或者后端 api 请求判断哪个 sy 文件发送了改变，上传了哪些文件，删除了哪些文件，禁止 fs，真正的按需同步，也比现在快，大家当然想要如果修改了 3 个字，就只做同步 3 个字的操作，但现在恐怕连修改了 3 个字就只同步这个文档的操作都没做到

这个是想表达，储存器性能根本不是原因，是自己没做足够复杂的中间件处理，最为全世界广泛应用的技术，对象存储已经是最好的云端存储方案了，就好像是，能不能让博尔特再快 5s，这样我看他跑步时间就更短了，有没有可能是自己阈值太高？

然后就是，我也没有把 live 看成是什么标杆，它也是早轮子而已

说白了，你觉得很简单的东西，像 live 做的监听对象，思源加了没有？最后我说这么多，我觉得最核心的还是这个

从去年讨论到现在，关于同步已经讨论了无数多个先进方案了。我的评价是，别自嗨，主要看 D 怎么说

所以你是觉得这样就算结构化了嘛。那这个要求和难度都不算太高，改善也不大就是了。这个实现无论是轮询还是系统监听都能做到，但是还是如上面所说，这方面再怎么改善也是提高了在快照上传到云端前的快照建立速度，但无论什么情况下，基本快照建立都不是主要时间。oss 的并发上传限制、思源保守的云端锁、快照分片数量、本地索引校验机制，无论哪一个的改善都远远比这个显著。

我个人觉得恰恰相反，这个不是为了减少本来就不慢的建立快照的时间，而可以解决我同步的时候，我直接知道我应该同步哪几个文件，而不用还要携带本来就应该是中间件写入储存器之前，供中间件自己建立同步流程用的零零碎碎的小文件，以及可以在让客户端拿到数据时尽量目标明确的去校验特定的文件

至于插件，插件确实会产生很多新文件的，特别是你进行了批量更新。一个插件最少带有 5 个文件，以我这里的例子来说平均是 29 个（49 个插件 1454 个文件），一次批量更新我们假设是 10 个插件，那么就会产生 300 个文件变动，假设每个插件只实际更新 50% 的文件内容，那么会实际产生个 150 文件变动。150 个变动文件假设大小都不大，每个产生一个分片，那么就总计 150 个分片、150 个文档索引、一个最新索引，在我的设备上，这个数据量意味着 300/20 = 15s+4s 总共 19s 的同步时间。当然，这是最好的情况下

有一点跑分测试的嫌疑了，实时上，批量更新插件，拉库这些，我相信大部分人都是主动点击之后在《等》的，也不是天天在点击，并不是影响平常同步体验的关键因素，ob 之前拉库更慢，一个小时都有，耐不住平常同步就是快啊，平常我按照十几个插件，他们也不会突然就产生或者修改几十个文件，一般涉及到这些操作，大部分用户都是主动点击然后《等》，反而不是最关键的因素，关键是因素是平常我就打几个字同步都这么慢

我觉得对等点本身就是一个服务端了吧……硬要这么说，思源也可以内部塞一个 webdav 或 s3 实现，然后直接通过局域网发现协议互相找到端口，进行同步。但是这种情况下思源自己就成为服务端了，这跟思源作为伺服的区别有多大呢？

区别就是思源只是现在的思源，而不是你口中的“要是怎么怎么样就行了”“思源也可以怎么怎么样”

然后就是关于你提供的代码定位，我当然可以跟着你看代码，可以看到，光是监听就写了

        plugin.registerEvent(plugin.app.vault.on("modify", this.watchVaultChange));
        plugin.registerEvent(plugin.app.vault.on("delete", this.watchVaultDelete));
        plugin.registerEvent(plugin.app.vault.on("rename", this.watchVaultRename));
        plugin.registerEvent(plugin.app.vault.on("create", this.watchVaultCreate));
        //@ts-ignore : Internal API
        plugin.registerEvent(plugin.app.vault.on("raw", this.watchVaultRawEvents));

五个，每一个事件不只是一个触发器来触发进行扫盘索引，而是拥有具体的返回对象，例如

   watchVaultChange(file: TAbstractFile, ctx?: any) {
        this.appendQueue([{ type: "CHANGED", file }], ctx);
    }

通过将文件的修改事件封装成一个对象，这个方法能够为后续的处理提供结构化的数据，这至少是一种基本的处理，至少是和操作挂钩了，返回校验也不需要重新牵一发而动全身

其他的我就不细看了，要休息

我们先假设，你这个测试是有意义的，思源是因为批量小文件拉慢了速度。那么，批量小文件不应该只在第一次下拉数据的时候吗？为什么要对批量小文件是对象存储应该考虑的问题？或者说，思源为什么每次同步都产生这么多批量小文件？我平常手写一秒只在一篇文档里写几个字，上传两三个附件，我真的修改了这么多的文件？人不是机器，很多人做不到无影手一下子修改那么多东西，哪怕是插件，也没有几个会平常一下子修改几十个文件，如果是因为自己的机制，每次一定要产生这么多校验文件，还真就是机制没做好

第一，我觉得你可能对对象存储有什么误解，对象存储的意义就是为了解决个人服务器带宽或者性能不够，然后提供一种按量计费的套餐，它的带宽是直接和腾讯从三大运营商拉过来的专线对等的，我再说的通俗一点，如果你家里宽带有 10000 兆的带宽，那么你下载腾讯 s3 的速度就是一万兆，你个人就算是硬盘提供得了这么大的速度吗？详情见这里，https://doc.fincloud.tencent.cn/tcloud/Storage/COS/845813/uploaddownloadfaq
对象存储的性能和带宽不上限，只按量，远超你自己局域网运行一个 docker 的性能

第二，我说了没有那么好的事情，即自由又稳定，况且，又不是没有解决方案，只需要把附件这种不会频繁变动的内容单独走另一个单独的上传信息通道就好了，而不是放到高频索引里面再扫一遍

第三，你也看了片段了，可以看到，它不是一个简单的索引触发器，更改的内容是由操作写入的，而不是索引对比文件，索引本身没有问题，问题是只有利用操作来写入索引才能让索引具有足够的时效性，这样做，同步的内容是和操作耦合的，而不是只和扫盘索引耦合，“数据分片”这个概念我也提到了，至少 ob 可以直接知道该同步哪一个 md 文件，思源可以在操作后马上知道该同步哪一个 sy 文件吗？倘若能，为什么要去扫盘？难道是因为我改了一个 sy 文件，每一次都要扫库看看我有没有改其他文件吗？那为什么不一直扫，万一我改了其他的文件但是没该文档，岂不是没有办法了，只能等我改文档的时候再帮我检测一下？这个思路倒是可以理解了。我是真的觉得，和用户的操作一块进行，监听哪些文件发生更改，然后没有中间服务商直接同步哪些文件，都比现在快。

第四，我知道你不停的强调建立一个快照或者索引有多快，但是，在我用的过程中，建立快照并不是卡我的原因，原因是这个快照索引本身就是没有时效性的，不可靠的，所以它不是建立完就没事了，他需要下载下来，然后解析，然后一个个核对，我的同步大部分时间就是花在这个核对索引上，一直在校验索引，少则校验 5-6s，多则半分钟，3.10 版本有时候校验索引都会卡死，扫盘建立的索引，终究还是要扫盘去核对

第五，我想表达的意思是，对象存储作为储存器并不是问题，问题是，没有一个很好的《中间件》来作为和对象存储的桥梁，anytype 的中间件，节点原理，即使塞到本体里面一样可以用（它也确实塞进去了），断网后，局域网内客户端是可以互相沟通同步的，每个客户端都具有与储存器之间的完整的中间件，而不是把储存器

同步应该与实时操作耦合，不然，我只能叫他频繁地扫盘备份，第三方备份这样做完全合理，甚至本应该就这么做，大家为了节省流量，或者因为没有同步感知，都会以较为低频的方式用，和 remotely-safe 基本上完全一个原理，但是官方同步，如果只是一个频繁地备份，我觉得至少不能作为一个优势，不说是缺点已经很不错了

然后我还想说一句，Anytype 的后端存储也是对象存储，冷备份热备份根本就和你用不用云端实例没有半毛钱关系，就看你有没有那个心思，有那个精力去做可以和系统运行时操作耦合良好的中间件，难道把 anysync 搬到我内网里边，它冲突解调就做不好了吗？一样可以的，它存储就不是用的对象存储了吗？也是用的对象存储

所以，真的别再说什么第三方修改了，思源的同步和自己的系统操作都耦合不好，省了事，就应该好好承担这些后果，别再做什么幻想了

另外，live 也就 md 同步快，在同步附件的时候还没有思源性能好，对于这种大 chunk 的东西，他貌似没有单独做数据上传流，也没有做数据切片

用的内核 api

自己搭建的 minio 吗？个人服务器性能一般都是丐中丐，如果是海外的对象存储，也比较拉跨，可以用腾讯云的对象存储试一下，运营商无带宽上限，只要不怕花钱，只要自己带宽够高，一天跑一套房子没问题

你说的外部修改因素我当然是有提及，不然也不会说禁止用户和插件通过思源调用 fs，我的评价是锁都锁了，直接禁止 fs 模块或者其他三方修改，被改了就报错，为什么要承担用户自己外部修改的责任？想要自由度又想要稳定性，哪里来的这么多好事，一切操作最多只通过 api 进行就是最合理的方法，或者直接打乱目录，防止本地有人直接修改本地明文

你说的只是对比索引然后增量同步而已，我很明确的指出了是只进行同步单个文档的操作，目前就和扫盘然后看一下哪里变了然后同步没什么区别

然后是上限问题，live 我是真真正正用过一段时间的，无论是服务器版本还是对象存储版本，我不认同你说的它是传统意义上的《冷备份》，甚至可以作为冷备份的上限，冷备份不是指云端没有实例可以实时通信，靠对象存储就是冷备份了，在运维系统里，冷备份通常是在系统离线的情况下进行的，通常需要停止应用程序或系统，然后对整个数据集进行备份。这种情况下，数据通常会被重新打包成一个一致性的备份文件或快照。这可以包括复制整个数据库、文件系统或其他存储介质。我概率中的同步，是指允许系统在运行时进行保持数据一致性，需要在系统运行时处理数据的一致性问题，同步通常比冷备份更复杂，同步需要和改动一样是结构化的，可传递的，可解析的，而不是单向发送的数据文件，应该属于系统的一个操作，思源就把它当做了独立与系统操作的另一个冷备份操作，自己多设备都要打架，再谈第三方有什么意义呢？而 live 并不存在这种情况，虽然没有实时通信的实例，但是它在本地运行了一个可以做到改动与同步同时进行的程序，没错，随着同步和改动一起进行，没有实例可以实时通信，那随着改动发生的结构化同步应该放到哪里呢？它从头造轮子，把同步操作缓存到了本地，而不只是一个简单的触发索引对比器，一切依旧具有结构化，从头造轮子把文件变动打包成了接近于 api 转发，结构化的请求，在我看来，它虽然没有做到真正的改动与同步同时进行，但是在改动发生时做到了实时存储改动信息，不需要在《每一次同步的时候》频繁扫盘索引，所以它的同步不管什么时候开始，同步携带的信息都是具有时效性的，数据切片也是和结构化数据一样最小的。