crclz

普通解决方案：
表的字段设置一个 UpdatedAt，一个 CreatedAt。写一个脚本，定期（ maybe 0.1s ）将新插入的记录或者修改的记录刷写到在 neo4j 中。同时在 neo4j 中记录这张表上次刷到哪个时间戳了，下次就从这个开始。注意时间戳的精度问题：java，c#的精度会和数据库中的不一样，会出大问题。所以就应该用 int64 存 UtcTicks。

进阶的：
这其实就是一主多从中的复制。看看有没有一个实用性广的解决方案，避免自己写过多的复制逻辑。

最高级的：
采用 CQRS+事件溯源。业务通过事件的形式写入（持久化的）消息队列。需要单独的程序根据事件定期增量式刷新物化视图（主要的）、更新某些（可能更加 denormalized 的）用于加速查询的数据库（例如 redis，neo4j ）。
缺点：实现复杂，并且业务多多少少需要一些强一致性来简化开发。

@chocotan 不用了。它们会录键盘。

@exceptionplayer1
首先建议考虑邻居的感受。
我高三的时候也神经衰弱了一段时间。挺难受的。我们楼上走动、打电话（吼大声）、冲厕所都听的到。那时候我还不知道耳塞这个东西。不过熬过来了。
如果你的走路的方式不对的话，或是拖鞋有点特别的话，走路也会听得见。关门也一定要慢关。
最简单的方法就是去他家实地听一下：你家里人在楼下听，然后你进行关门、走路等活动。然后你去下面听，家里人在上面模拟活动。

@korokke 安耳悠是真的行！！！

@lijunnan 3M 冬天可以，夏天塞不进去。

《技术内幕》

@encro 运动后会减轻 那是因为运动后免疫力下降

@loqixh 网上我看过一些评测，发现都是 go （的某个框架）优于.net core

@xingheng @xuanbg 回复一直发不出来，截断后发出来了。

这篇文章中貌似还说，其实所有类似的（例如线程池，选择最佳的线程池大小），也基本适用于这个公式。
也就是说，线程池的大小有一个最优的大小。在这个最优的大小下，你的吞吐量、响应时间最优。

这个最优的大小由 C#管理，程序员不用操心。

而 C#的 Task 是什么？ Task 可以简单的理解为“任务”。你不用关心这些“任务”是如何完成的，你只需要知道：可以用 DoSomethingAsync()来开启一个 Task （并获得该 Task 实例）、可以用 await SomeTask 来等待 Task 结束。至于如何完成 Task 的任务，则是 c#的事情——c#会高效利用线程池里的资源，来完成“任务”：在 await 一个阻塞性的 task 时，没有线程会被拿来等待（这也是传统多线程方式无法企及的）。一个 Task 可能会先后被 1 个、2 个、5 个或者多个 worker thread 接手，但这些东西开发者都不需要关心。又由于线程池里 worker thread 的数量设计很合理，所以这种方法能达到最优的表现。

唯一的缺点就是，要严格控制代码（或许 VS 的各种 analyzer 包能容易的做到这一点），不能出现传统的同步阻塞式方法 例如 File.Read()；而是要将它们全都换成 await File.ReadAsync()这种。因为线程池的 worker thread 资源是很宝贵的：核心*2+硬盘数，在 4 核 cpu 下，这个值仅仅为 9。c#可能有一套更优的公式，但也离这个值不远。一旦 worker thread 中运行了同步阻塞式代码，宝贵的线程池资源会被浪费。可能造成 threadpool exhaustion 等问题（这个我不是很懂）,但至少会让吞吐量下降到 线程池大小 /响应时间。

相比来说，感觉 go 的并发代码编写方式、内部实现都很可以。希望 .Net Core 早日达到 go 的性能。