@misaka19000 用 tcpdump 貌似发现了一点规律

@jatsz 嗯，其实很难复现。用 curl -v 很快

@misaka19000 嗯，正抓着呢，希望能发现点什么。

@starsky007 它也会出现偶尔 12s 的握手时间

@hronro 你说的对。不过一旦所有节点和 lighting house 建立了连接，那 lighting house 就可以和所有节点通信。如果我们再配置上 unsafe route，那就变成 lighting house 可以和所有节点后面的子网进行通信。这个时候，我们就可以把 lighting house 当成一个路由器用了，配置一些 iptable nat 规则，就可以对每个节点后面的子网相互转发数据。

@hronro 老帖子了。确实，udp2raw 只能解决 lighting houre 和其他节点的通讯问题。其他节点之间的通讯，全靠 lighting
house 转发:doge:

@Suclogger prometheus+grafana 跑通，相当不错的工具。

@ajaxfunction 在同一个子网内，树莓派 A 发起向树莓派 B 的请求之后，内部会做一次 ARP，将目的 IP 地址转换成 MAC 地址，然后再发出数据包。

交换机收到数据包之后，查询数据包二层帧就能找到目的 MAC 地址所对应的端口，就会将数据直接发送给树莓派 B，而不是再往上传递给网关。

@bboymega @szqhades 我记忆中，貌似如果是同一网段的局域网设备，不需要网关 /路由器就可以通讯。是不是这些数据其实都不经过网关的。

@Microseft 是二层交换机结构。一共分布在三层楼，每层一个大交换机，然后大交换机层叠到另一台大交换机。现在的情况是，即使在同一层的设备，速度也上不来。

@Suclogger 4 代树莓派，我在测试环境跑到几百兆问题不大。prometheus+grafana 我试下

升级到最新版，错误消失

单臂路由。https://www.v2ex.com/t/453362

@wd 感谢，确实是这样，大概等了两分钟文件变化了。

@wd 嗯，是的，会生成一个 secret，mount 成 pod 中的一个文件。我的 go 程序会检测这个文件是否变化（通过 certman ）来决定是否重新读取。但是似乎没有生效。但是重新启动 pod 会生效。

@lychs1998 嗯，但是实际上，即使插入的时候，数据是不冲突的。但是当做了一次批量任务延期后，就会出现冲突了，后面还需要操作者微调下几个冲突的任务。所以我觉得从插入的地方去堵不是很合适。我做了一版在修改任意任务后，都去查找下这个任务的冲突项。查询数据库次数有点多，先线上跑一跑试试。

@lychs1998 厉害了。确实后面还要考虑您说的“标准工时”“实际效率”这些。请问，对于“标记冲突的任务”，是在修改任务时候实时的去标记了，还是异步去处理的。

额，我头晕了。我错了。应该是这个场景：task 由于有优先级更高的任务插入，导致某个任务需要延后一天。像下面的图那样子。https://sm.ms/image/J6aZn1VsqQvMyXS

如果用 homeassistant 的话，如果家里的 wifi 是 unifi 的话，可以用 Ubiquiti UniFi 模块中的 presence detection 和 switch，前者判断是否在家，后者可以控制禁止摄像头接入 wifi 。加一条自动化就可以了。