最近我的 FreshRSS 阅读器出了一个怪现象：用来实现智能刷新订阅源的 AutoTTL 扩展在这个月初突然“罢工”了。具体表现为，我手动点击刷新后，它能按调整后的 TTL 时间更一次，之后就彻底“躺平”。所有订阅源的「下次更新时间」都卡在 pending，关掉 AutoTTL 反而能恢复正常自动刷新。

这问题有点意思，像是某个环节的状态机卡住了。作为一个喜欢刨根问底的人，我花了点时间深入排查，最终发现问题的根源竟是一个看似不相关的数据库警告。记录一下这次排查的全过程，给遇到类似问题的博友一个排故参考。

FreshRSS 自动更新问题描述

FreshRSS 部署情况

• 运行环境：FreshRSS 与 PostgreSQL 均部署在 Docker 容器中。
• 软件版本：FreshRSS：V 1.27.1；PostgreSQL：V 15.15；AutoTTL： V 0.5.9。

FreshRSS 诡异现象

1. 在 FreshRSS 管理页面点击“手动更新”，所有订阅源能正常刷新。
2. AutoTTL 插件会在设定的 TTL 时间到达后，成功执行一次自动更新，刷新全部订阅源（其实并不，只是当时我以为是全刷新了）
3. 但在此之后，所有订阅源的“下次更新时间”全部显示为 pending，AutoTTL 的自动调度机制似乎完全停止工作。
4. 关键线索：关闭 AutoTTL 扩展后，FreshRSS 基础的计划任务反而能正常定时刷新。

FreshRSS 自动更新问题初步判断

问题的核心矛盾点很明确：

• 手动刷新有效：说明 FreshRSS 的核心更新脚本 actualize_script.php 和网络连接本身没问题。
• AutoTTL 自动调度失效：说明负责定时触发更新的“闹钟”——也就是 Cron 服务，或者 AutoTTL 扩展自身出了问题。
• 关闭 AutoTTL 后正常：这几乎将矛头直接指向了 AutoTTL 扩展。我第一感觉是插件冲突或者插件本身 Bug 了。

FreshRSS 自动更新问题排查

最讨厌这种“时灵时不灵”的问题，因为手动刷新后，AutoTTL 扩展居然还能正常工作一次（其实并不是正常工作，只是当时我没发现而已。其实这次会在更新到一半时卡住，但因为会更新一部分订阅源所以我当时一直以为订源被全部更新了）

第一步：先确保自己是在用最新版的软件

首先重新拉取一次镜像，并检查AutoTTL 扩展的实际版本，确保他们都是最新版，以防这个 bug 其实早就被修复了，只是我没更新，或者是两者某一方更新后，另一方没更新导致的兼容性问题。
经过检查，确认目前，FreshRSS、PostgreSQL、AutoTTL都是他们各自的最新版本了。

第二步：看眼前端日志

看眼日志里都有点啥问题，是不是某个订阅源有问题，导致卡死在它上边了
虽然日志中有很多类似报错

cURL error 28: Operation timed out
HTTP 503 Service Unavailable!
HTML+XPath Web scraping failed for 
Error fetching content: HTTP code 0: Could not resolve host:

但这基本都是订阅源本身的问题，比如触发了源的抓取频率限制，源站服务器卡了。并没有发现会引起订阅源无法更新的故障。于是这时我感觉肯定是扩展的锅，于是就跑去 github 给 AutoTTL 发了个 issues。
扩展作者mgnsk的回复提醒了我“How often does your cron run? A pending status means that the time for updating the feed has arrived but cron has not run yet.（cron 每隔多久运行一次？挂起状态意味着更新 feed 的时间已到，但 cron 尚未运行。）”

第三步：检查 Docker 内的 Cron 服务

FreshRSS 的自动更新依赖于容器内的 Cron 服务定时执行任务，既然自动更新卡住，那就先检查 cron 是不是正常工作。

1. 这里为了行文方便，先假定一些配置

   FreshRSS本体容器名：freshrss-app
   PostgreSQL数据库容器名：freshrss-db
   PostgreSQL数据库用户名：freshrss
   PostgreSQL数据库密码：freshrss
   

2. 进入容器：首先得进到容器内部看看。

   docker exec -it freshrss-app /bin/bash
   

3. 检查 Cron 状态：看下是不是 cron 服务宕了
   输入 service cron status，结果显示 cron is running.。嗯，系统级的 cron 在正常走，没问题。

4. 查看定时任务：看看具体定时任务是什么

   执行 crontab -l，看到了关键配置：

   */21 * * * * . /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 2>> /proc/1/fd/2 > /tmp/FreshRSS.log
   

这个配置设计得很周到：先加载环境变量文件，然后切换到 www-data 用户执行更新脚本，还把日志重定向了。

5. 手动执行定时任务：
   先不带参数执行一下试试
   • 直接键入 php /var/www/FreshRSS/app/actualize_script.php ：结果直接罢工了，好吧看来环境变量是必须的。
   • 那就带上参数试试. /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 结果订阅源正确刷新了！ 这说明Docker内，cron设置的更新命令本身和权限设置都是正确的，所以如果不使用 AutoTTL 时能正常更新是理所应当的。

第四步 研究下 AutoTTL 是如何工作的

AutoTTL 的工作原理，其实就是
1. 先根据每个订阅源历史上的平均更新间隔，最短更新间隔，计算出每个不同的订阅源，最合适的刷新间隔。
2. 拦截系统的cron，让他不是刷新所有订阅源，而是改为触发 AutoTTL，由 AutoTTL 去判断本次 cron 应该去刷新哪些订阅源。
3. 就在这时，我注意到了一个事情：AutoTTL 会往数据库里写数据并计算排序他们 既然刚才手动执行系统级 Cron 任务能成功，为什么自动运行时 AutoTTL 就不行呢？差别就在于“手动”和“自动”之间的环境差异。我意识到，刚才的输出信息我还没仔细看。

第五步：回头再看一眼刚才被忽略的警告日志

再次手动执行 Cron 任务，但这次我紧紧盯着终端输出。果然，在一堆刷新成功的提示信息之间，发现了一条 WARNING：

WARNING: database "freshrss" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE freshrss REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

这个警告来自于 PostgreSQL 数据库。大意是：数据库的排序规则版本和操作系统提供的版本不匹配。通常是因为系统底层库升级了，但数据库对象还用的是旧规则。
我想起来，月初时服务器宕机了一次，被我顺势维护了一番，当属将所有能更新的 docker 都手动更新了一次，而日常docker 的自动更新是由 Watchtower 做的，为了稳定性，我并不允许 Watchtower 去更新 docker 中的数据库版本，这次我看 PostgreSQL 只是一个小版本升级（ 15.14 → 15.15 ）更新日志中没改啥东西，就顺手也给升级了。

第六步：修复数据库排序规则

根据警告信息的提示，我们需要对 PostgreSQL 数据库进行操作。

1. 连接至 PostgreSQL 数据库：

   # 进入 PostgreSQL 的容器，使用 psql 客户端连接
   docker exec -it freshrss-db psql -U freshrss -d freshrss
   

2. 重建数据库索引（重要）：
   在数据库连接中，执行以下 SQL 命令。执行以下命令，重建所有使用默认排序规则的数据库对象（主要是索引）以确保其与新版本的规则兼容。

   REINDEX DATABASE freshrss;
   

   这个过程可能会花费一些时间，取决于你数据库大小。

3. 刷新数据库的排序规则版本：
   重建完成后，重建完成后，执行 WARNING 提示中的命令，更新数据库的系统目录版本：

   ALTER DATABASE freshrss REFRESH COLLATION VERSION;
   

4. 在freshrss中手动刷新一次订阅源，耐心等待了下一个 Cron 周期…………好了 AutoTTL 正常工作了，订阅源能够按照 Adjusted TTL 定期自动更新，完成故障修复。

FreshRSS 自动更新，为什么因为“警告”就会导致故障？

我推测是这样的机制

1. 系统级 Cron 按时启动，AutoTTL拦截 Cron。
2. AutoTTL 开始工作，首先它会连接数据库，准备获取需要更新的订阅源列表。
3. AutoTTL 连接数据库执行初始查询，排序订阅源列表，确定现在哪些订阅源需要更新。
4. PostgreSQL 输出了这个排序规则不匹配的警告。这个警告信息可能被 AutoTTL 的错误处理机制捕获，导致脚本的执行流程被意外中断或挂起，但又没有抛出致命的错误，所以 FreshRSS 的日志中也不会有记录。
5. 于是，AutoTTL “静默”失败了。对 AutoTTL 插件来说，它感知到的状态就是“上一次更新任务启动后没正确结束”，所以它不敢再调度新的任务，所有状态便卡在了 pending。
6. 当我手动刷新时，绕过了 AutoTTL 的排序步骤， AutoTTL 只记录订阅源的最后刷新时刻，所以更新能成功。

总结与教训

1. 不要忽视任何警告（Warning）：尤其是数据库、系统底层的警告。它们可能不会立即导致服务崩溃，但会像“慢性病”一样，在特定条件下引发诡异的行为。
2. 日志是救命的黄金：不要感觉如果能跑 WARNING 日志就不需要，而只记录 ERROR 日志。这次如果放过日志中的 WARNING ，我可能还在插件代码里兜圈子。
3. 数据库升级需谨慎：在这之前我只锁死大版本，谁能想到这次小版本升级都能出事，Docker 官方实打实的给我上了一课。
4. Docker跑数据库需指定精确的版本号：数据库的 docker 镜像一定要写死版本，绝对不要使用 latest 标签，务必使用精确的版本号，以确保部署的一致性。最好连 Debian 版本号也指定上，也就是 17.6-bookworm 这样的版本号。为什么？比如这次的小版本更新中实际 隐含着一次 Linux 操作系统大版本升级。 你以为自己只是从 PostgreSQL 15.14 升级到 PostgreSQL 15.15 只是数据库的一次小版本号升级，但实际上 Docker 官方提供的 PostgreSQL 镜像，这次把运行 PostgreSQL 的操作系统从 Debian 12 升级到了 13 。这就导致 C 函数库 (glibc) 版本出现了跃迁 —— glibc 版本从 Debian 12 的 2.36 升级到了 Debian 13 的 2.41，而在这两个 glibc 版本中，排序规则发生了变化，这也就是本次故障产生的核心原因所在。

希望这篇记录能帮到遇到类似问题的朋友。如果你的 FreshRSS 或者其他使用了 PostgreSQL 的Docker 也出现了什么灵异现象，不妨先去检查一下数据库日志，说不定会有惊喜（或者说惊吓）。

具体这次 Docker 官方在 PostgreSQL 升级时做了什么，可以参考这篇文章《原地报废：不要在生产环境用Docker跑PostgreSQL！》

The post FreshRSS 自动更新订阅源失效排查：AutoTTL 扩展失效竟是 Docker 官方埋下的坑 appeared first on 秋风于渭水.

不要使用分布式锁

就像 Martin Fowler 说的那样，“分布式调用的第一原则就是不要分布式”，谈分布式锁也要先说，不要使用分布式锁。原因很简单，分布式系统是软件系统中复杂的一种形式，而分布式锁是分布式系统中复杂的一种形式，没有必要的复杂性就不要引入。

有的逻辑是没有副作用的（纯函数代码），那就可以无锁执行；有的数据经过合理的 sharding 之后，可以使用单线程（单节点）执行，那就单线程执行。

比如一种常见的模式就是使用 queue（比如 Kafka），任务全部放到队列中，然后根据 sharding 的逻辑，不同的 consumer 来处理不同的任务，互相之间不会干扰冲突。

还有一个例子是 Kotlin Coroutine，通过指定一个单线程的 dispatcher，也可以保证它执行的操作之间互相不会有多线程的冲突问题。

有了这样的原则以后，再来谈谈几种分布式锁。

数据库锁

分布式系统中，我觉得我们最常见的锁就是使用一个中心数据库来做的。

一种是悲观锁，就是 “select xxx … for update” 这样的，相应的数据行会被锁上，直到 commit/rollback 操作发生。如果被别人锁了，当前线程没得到锁的话就会等着。

还有一种是乐观锁，就是使用版本号，“update … where … version=A” 这样的。如果 update 成功，表示获取锁成功，并且操作也成功；否则就是 update 失败，需要重新获取状态再来操作一遍。

大多数情况下，后者要更高效一些，因为阻塞的时间通常更短，不过在锁竞争比较激烈的情况下，反而效率会反过来。另外一个，悲观锁代码写起来会容易一些，因为 select 语句执行和 commit/rollback 是两步操作，因此二者之间可以放置任意逻辑；而乐观锁则是需要把数据的写操作和 version 的比较放在一条语句里面。

这两种都很常见，基本上我接触过的一半以上的项目都用过两者。这个数据库不一定非得是关系数据库，但是强一致性必须是保证的。

S3

使用 S3 来创建文件，让创建成功的节点得到锁，文件里面也可以放自定义的内容。我们去年的项目用到这个机制。这种方式是建立在 S3 2020 年 12 月 1 日，上线的 strong consistency 的 feature。

大致上，有这样两种思路：

1. 使用 S3 versioning，就是说，在 versioning 打开的情况下，文件的写入不会有 “覆盖” 的情况发生，所有内容都会保留。在创建文件的时候，response 种会有一个 x-amz-version-id header。节点写入文件后，再 list 一下所有的 version，默认这些 version 会根据创建的时间顺序递减排列，后创建的在前，因此比较其中最早的那个 version 和自己创建文件后得到的 version，如果两者相等，说明自己得到了锁。
2. 使用 S3 Object Lock，这个可以控制让第一次写成功，后面的操作全部失败，所以第一次写入成功的节点得到锁。

使用这种方式，对于那些本来就需要使用 S3 文件系统来共享任意信息的情况很方便，但是需要自己处理超时的问题，还有 retention 策略（该不该/什么时候删掉文件）。

Redlock

Redlock 就是 Redis 的锁机制。Martin Kleppmann（就是那个写《Design Data-Intensive Applications》的作者）几年前写过一篇文章，来吐槽 Redlock 在几种情况下是有问题的：

1. Clock jump：Redlock 依赖于物理时钟，而物理时钟有可能会跳（jump），并且这种状况是无法预测的。Clock jump 就是说，始终会不断进行同步，而同步回来的时间，是有可能不等于当前时间的，那么系统就会设置当前时间到这个新同步回来的时间。在这种情况下，依赖于物理时间的锁逻辑（比如超时的判断等等）就是不正确的。
2. Process pause：得到锁的节点，它的运行是有可能被阻塞的。比如 GC，下面这个图说的就是这个情况——client 1 一开始得到锁了，执行过程中有一个超长时间的 pause，这个 pause 导致锁超时并被强制释放，client 2 就得到锁了，之后 client 1 GC 结束，缓过来后恢复执行，它却并没有意识到，它的锁已经被剥夺了，于是 client 1 和 client 2 都得到了锁，对于数据的修改就会发生冲突。
3. Network delay：其实原理和上面差不多，网络延迟+锁超时被强制剥夺和重分配的逻辑，在特定情况下就是不正确的。

问题可以理解，可是仔细想想这个问题的本质是什么？它的本质其实就是消息延迟+重排序的问题，或者更本质地说，就是分布式系统不同节点保持 consistency 的问题，因为 lock service 和 client 就是不同的节点，lock service 认为之前的锁过期了，并重分配锁给了 client 2，并且 client 2 也是这样认为的，可是 client 1 却不是，它在 GC 之后认为它还持有者锁呢。

如果我们把数据的写操作和锁管理的操作彻底分开，这个问题就很难解决，因为两个节点不可能 “一直” 在通信，在不通信的时间段内，就可能会发生这种理解不一致的情况。但是如果我们把写操作和锁管理以某种方式联系上，那么这个问题还是可以被解决的。简单说，就是物理时钟不可靠，逻辑时钟可以解决这个问题。

之后 Martin Kleppmann 提出了解决方案，他的解决方案也就是按照这个思路进行的。他的方法很简单，就是在获取锁的时候，得到一个永远递增的 token（可以被称作 “fencing token”），在执行写操作的时候，必须带上这个 token。如果 storage 看到了比当前 token 更小的 token，那么那个写操作就要被丢弃掉。

Chubby

Chubby 是 Google 的分布式锁系统，论文在这里可以找到，还有这个胶片，对于进一步理解论文很有帮助。从时间上看，它是比较早的。

Chubby 被设计成用于粗粒度的（coarse-grained）锁需求，而非细粒度（fine-grained，比如几秒钟以内的）的锁需求。对于这样一个系统，文中开始就提到 consistency 和 availablity 重要性要大过 performance，后面再次提到首要目标包括 reliability，能够应对较多数量的 clients，和易于理解的语义，而吞吐量和存储容量被列在了第二位。

Chubby 暴露一个文件系统接口，每一个文件或者文件夹都可以视作一个读写锁，文件系统和 Unix 的设计思路一致，包括命名、权限等等的设计都是基于它。这是一个很有意思的设计。

对于一致性的达成，它使用 Paxos，客户端寻找 master 和写数据都使用 quorum 的机制，保证写的时候大部分节点成功，而读的时候则是至少成功读取大部分节点（R+W>N，这个思路最早我记得是 Dynamo 的论文里面有写）；如果 lock 有了变化，它还提供有通知机制，因为 poll 的成本太高。

内部实现上面，每一个 Chubby 的 cell 都是由作为 replica 的 5 个服务节点组成，它们使用 Paxos 来选举 master 和达成一致，读写都只在 master 上进行（这个看起来还是挺奢侈的，一个干活，四个看戏）。如果 master 挂掉了，在 master lease 过了以后，会重新选举。Client 根据 DNS 的解析，会访问到该 cell 里面的某一个节点，它不一定是 master，但是它会告知谁是 master。

分布式锁里面比较难处理的问题不是失败，而是无响应或者响应慢的超时问题。Chubby 采用一种租约的机制，在租约期内，不会轻易变动当前的 master 节点决定。在响应超时的时期，客户端的策略就是 “不轻举妄动”，耐心等待一段时间等服务端恢复，再不行才宣告失败：

这个图的大致意思是，第一次租约 C1 续订没有问题；第二次租约续订 C2 了之后，原来的 master 挂了，心跳请求无响应，这种情况客户端不清楚服务端的状况，就比较难处理，于是它只能暂时先阻塞所有的操作，等到 C2 过期了之后，有一个 grace period；接着再 grace period 之内，新的 master 被选举出来了，心跳就恢复了，之后租约续订的 C3 顺利进行。

这显然是一个异常情形，但是一旦这种情况发生，系统是被 block 住的，会有非常大的延迟问题。思考一下，这种情况其实就是从原来的 master 到新的 master 转换的选举和交接期间，锁服务是 “暂停” 的。再进一步，这个事情的本质，其实就是在分布式系统中，CAP 原理告诉我们，为了保证 Consistency 和 Partition Tolerance，这里的情形下牺牲掉了 Availability；同时，为了保证 consistency，很难去兼顾 performance（latency 和 throughput）。

此外，有一个有点反直觉的设计是，Chubby 客户端是设计有缓存的。通常来讲，我们设计一个锁机制，第一印象就是使用缓存会带来复杂性，因为缓存会带来一致性的难题。不过它的解决办法是，使用租约。在租约期内，服务端的锁数据不可以被修改，如果要修改，那么就要同步阻塞操作通知所有的客户端，以让缓存全部失效（如果联系不上客户端那就要等过期了）。很多分布式系统都是采用 poll 的方案——一堆 client 去 poll 一个核心服务（资源），但是 Chubby 彻底反过来了，其中一个原因也是低 throughput 的考虑，毕竟只有一个 master 在干活。

对于前面提到的 Martin Kleppmann 谈到的那个问题，Chubby 给了两个解决方法：

1. 一个是锁延迟，就是说，如果一切正常，那么持有锁的客户端在释放掉锁之后，另外的客户端可以立即获取锁。但是如果出现超时等等异常，这个锁必须被空置一段时间才可以被分配。这个方法可以降低这个问题出现的概率，但是不能彻底规避问题。
2. 第二个就是使用序列号了，对于写入操作来说，如果请求携带的序列号要小于前一次写入的序列号，那就丢弃请求，返回失败。

回过头思考 Chubby 的实现机制，我觉得有这样几个启发：

1. 不要相信任何 “人”（节点），必须询问到多数人（quorum），多数人的结论才可以认为是正确的。这个方式发生在很多操作上，比如寻找 master，比如选举 master，比如写数据。
2. 超时是很难处理的，它采用了租约的机制保证节点丢失时间的上限，使用 grace period 来容忍 master 选举发生的时延，使用序列号来保证正确性。

《四火的唠叨》文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接

本文介绍了 Neo4j Server 的不同部署方式，并以豆瓣电影图谱数据为例说明了不同的数据导入方式，并简单介绍了 Cypher 查询语言的使用。

tar xzvf neo4j-community-3.5.5-unix.tar.gz
mv neo4j-community-3.5.5 /opt/neo4j/
export PATH=$PATH:/opt/neo4j/bin

docker pull neo4j:3.5.5
mkdir $HOME/neo4j/data -p
docker run -p 7474:7474 -p 7687:7687 -v $HOME/neo4j/data/:/data neo4j

call dbms.listConfig()

call dbms.listConfig("dbms.connectors.default_listen_address")

git clone https://github.com/Linusp/kg-example

(shell) $ cd kg-example
(shell) $ tree movie
movie
├── actor.csv
├── composer.csv
├── Country.csv
├── director.csv
├── district.csv
├── Movie.csv
└── Person.csv

0 directories, 7 files

neo4j-import --into graph.db --id-type string \
             --nodes:Person movie/Person.csv    \
             --nodes:Movie movie/Movie.csv \
             --nodes:Country movie/Country.csv \
             --relationships:actor movie/actor.csv \
             --relationships:composer movie/composer.csv \
             --relationships:director movie/director.csv \
             --relationships:district movie/district.csv

IMPORT DONE in 3s 692ms.
Imported:
  27608 nodes
  54844 relationships
  91628 properties
Peak memory usage: 524.24 MB

mkdir $HOME/neo4j/data/databases -p

docker run -v $PWD/movie:/movie:ro -v $HOME/neo4j/data:/data/ \
       neo4j neo4j-import --into /data/databases/graph.db --id-type string \
             --nodes:Person /movie/Person.csv    \
             --nodes:Movie /movie/Movie.csv \
             --nodes:Country /movie/Country.csv \
             --relationships:actor /movie/actor.csv \
             --relationships:composer /movie/composer.csv \
             --relationships:director /movie/director.csv \
             --relationships:district /movie/district.csv

docker run -p 7474:7474 \
       -p 7687:7687 \
       -v $HOME/neo4j/data/:/data \
       -e NEO4J_AUTH=neo4j/neo4j_password \
       neo4j

CREATE INDEX ON :Movie(id)

CREATE INDEX ON :Person(id)

CREATE INDEX ON :Country(id)

[
    {
        "id": "person1",
        "name": "张志昂",
        "age": 23
    },
    {
        "id": "person2",
        "name": "刘文刀",
        "age": 18
    },
    {
        "id": "person3",
        "name": "孙子小",
        "age": 22
    }
]

POST http://neo4j:neo4j_password@localhost:7474/db/data/cypher
Content-Type: application/json
{
    "query": "UNWIND {values} as data CREATE (:Person {id: data.id, name: data.name, age: data.age})",
    "params": {
        "values": [
            {"id": "person1", "name": "张志昂", "age": 23},
            {"id": "person2", "name": "刘文刀", "age": 18},
            {"id": "person3", "name": "孙子小", "age": 22}
        ]
    }
}

import requests

url = "http://neo4j:neo4j_password@localhost:7474/db/data/cypher"
payload = {
    "query": (
        "UNWIND {values} as data "
        "CREATE (:Person {id: data.id, name: data.name, age: data.age})"
    ),
    "params": {
        "values": [
            {"id": "person1", "name": "张志昂", "age": 23},
            {"id": "person2", "name": "刘文刀", "age": 18},
            {"id": "person3", "name": "孙子小", "age": 22}
        ]
    }
}
requests.post(url, json=payload)

import neo4j

client = neo4j.GraphDatabase.driver(
    'bolt://localhost:7687', auth=('neo4j', 'neo4j_password')
)
with client.session() as session:
    query = (
        "UNWIND {values} as data "
        "create (:Person {id: data.id, name: data.name, age: data.age})"
    )
    values = [
        {"id": "person1", "name": "张志昂", "age": 23},
        {"id": "person2", "name": "刘文刀", "age": 18},
        {"id": "person3", "name": "孙子小", "age": 22}
    ]
    session.run(query, {'values': values})

MATCH (p:Person) where p.name="黄渤" RETURN p

PROFILE MATCH (p:Person) where p.name="黄渤" RETURN p

最近迁移服务器，并且搞了一个1P专业版玩玩，感觉效果很不错，想找一个管理数据库的服务，其中看了phpmyadmin等一些知名项目，但是都不太符合我的要求，最后经过筛选，找到了比较合适的，分享给大家！