sujin190

只同步数据的话那分享下项目

https://github.com/snower/syncany-sql

把 SQL 当作脚本执行，内部有自动依据主键增删改同步数据的逻辑，可以用 crontab 来调用

set @use_output_type='UPDATE_DELETE_INSERT';
insert into `pg2`.`adata` select `id`, `name`, `create_time` from `pg1`.`bdata` where `id`>=2;

使用 set @use_output_type 设定更新目标库方式，可选值有 INSERT 、UPDATE_DELETE_INSERT 、UPDATE_INSERT 、DELETE_INSERT ，不设置时和正常 insert into 一样默认 INSERT ，select 的第一个字段自动认为是主键，相同主键执行 update ，否则插入

大概率不能，串口就没状态线

nfs 呗，直接挂载磁盘

在你这假设下，宇宙有没有都不好说，还关心啥世界啊

19 金币了。。

@chaleaochexist 可以这么认为，数据层是对数据准确、严谨并且完整无歧义的读写封装，理论上不应该和具体的需求场景上有关联，虽然吧数据结构完全是按产品和业务需求来设计的，但在软件分层架构中按产品和业务需求设计完数据结构后，我们却首先应该抛弃产品和业务的具体需求和场景，完全按照数据结构自身来设计标准数据读写封装层，而且吧现实情况下太多时候一个具体的产品和业务需求可能只有一个数据读写，如果没按标准分层架构设计，后续一部分变更需求逻辑后，很大可能就越来越混乱一塌糊涂了

数据层和业务层不难区分吧，数据层主要封装的是对数据结构逻辑的读写，这个包含着完整数据逻辑，大多数情况下一个数据逻辑只有一个读写操作，但有时候也会有多个，也许层对应的自然是现实需求和产品表达的具体实现了

举个简单例子，判断是都是超级用户这显然是一个数据逻辑，在用户登陆成功后需要判断是否是超级用户提示不可用这显然是业务逻辑

数据层不应该对应使用场景，而业务层必定应该对应具体使用场景，就这样啊

@hez2010 话说似乎 garnet 是多核多线程的吧，redis 似乎是单线程的，应该是负载一样的来比吧

@hez2010 没懂你这是服务端多线程还是测试工具多线程，否则就算单核也不可能这么低吧，话说咱要测的是服务端性能吧，而且差距这么大 128 核心？