@Morgan2 因为他故事框架没啥敏感的吧？是 R 级片 是不是因为有少量情欲描写？，这部分事实上 在部分国家上映的时候都有调整

《奥本海默》不难懂吧，不需要什么 物理/量子力学 的背景知识，毕竟纪实电影嘛，无非叙事方法上 显得可能有点乱？，但也还好，我是开幕了几分钟才进去的，经历 几分钟 懵逼也能掌握的叙事的方式，后面看起来就没压力了，不过我确实不怎么喜欢，对这种纪实类型比较无感，但并没有让我昏昏欲睡，诺兰还是 nb 的

aws 国内可以用吧？我就用国内信用卡啊，还有电话推销呢

看业务需求，不要被“脚本”二字束缚住了手脚，关键是业务需求是如何的，并不是一定要是一个 script, 因为 `脚本` 本身还是个技术 term, 因为这限制业务分析舍本逐末了

作为一个 平台，对外的提供可扩展能力, 其实目的也不一样啊

是需要 一个 glue lang 来调用平台 api, 实现灵活的逻辑呢？ ( 这可能比较符合传统很多 script 的定位, 比如 lua 定位就是作为 glue lang 存在)

还是需要接入其他三方生态（ 比如允许加载 自定义 jvm class 很多 jvm 生态里的东西也许有可能接入）

等等...

总的来说，具体问题具体看，心态开放点呗，尽量不用自己领域的知识向外，不然很累。

我很喜欢
--
如何反馈:

Help-> Submit Feedback...

or

取消订阅，这样你的意见就反应在他们的营收上了 QAQ

title 和 content 描述的没啥关系啊,

路由的过程就是查表: 依据 packet dip 查找下一跳地址

NAT 也是查表: 会 记录 intra ip, sport, dip, nat port 的对应关系,(表中项不一定，实现会不一样）, 这样 回包的时候，就能找到 原来发包的 intra ip 和 sport

obs, 不过就像上面说的, 根据你要露的内容调整下 分辨率, 码率, 帧率 等参数

我 5 月份被拖去顶了个项目，甲方要求录屏留档，第一天用 macos QuickTime 录一天 8 小时 结果 20G, 换 obs ，1920x1080 10Hz 就两造出头

唯一问题就是在我的电脑上没有硬件编码

@thevita

文件同步的方案我觉得不一定不行，如果规模就是这么大，存储又能接受，是可以的，关键是简单
至于以上说的弱点:
a) 带宽问题，目前也不大吧，完全用不着 rsync 这样的，搞个什么简单的单向同步就行了（反正也需要保证不会冲突），带宽利用率还是很高的，rsync 需要 diff 完全没必要嘛
b) 巨量小文件是个问题，但是还是看场景的，况且也不是不能优化

题主没把 workload 说清楚

1. 看写文件会不会有冲突, 如果能避免冲突(比如 append only+ node_id 分区文件名/目录) 就可以多机分别写
2. 读的 pattern 和要求是怎么样的，一致性要求？目录同步必然不能强一致, 读 pattern 是怎么样的，随机/还是顺序？ 是否存在热点读

根据以上可选的有，比如：

1. 最好当然是有比较好的共享存储设备/集群, 比如有单独的团队，不用管运维，多好
2. 可以避免写冲突且容忍最终一致性，可以设计一些文件同步逻辑 来同步，好处是可以利用本地 io 来处理比较高的 iops ，也比较简单
3. 如果读有热点可以 cache + s3 这样的低成本方案也行啊

@thevita 屑，说错了，忽略我

要辩你应该先陈述自己的观点，不应该是问句

ps:
remove(int index) 复杂度 O(N2) 写错了吧。remove(Object o) 才是 O(N^2)

想到一个比较破的方案：

就是你在 db 里面 预先 “生成， 分配” 一批 id （假设这里你的 全局有序 id 是主键）

这样就能让服务来`抢` next id, 对 行加锁了，并发应该会好一些，

就是不能回滚，需要让签名的 id 失效

还不如看看你的需求只是要 “递增“ 呢，还是真的需要严格的全局有序

2L 第二种也是一个办法，相当于 用 db 作为一致性保证？，乐观冲突检测的方式来做，但是 db 的事务的貌似还是得依赖全局锁的方式来支持 insert id 有序

2L 提的第一个方法与 1L 本质上是一样的，都是引入一个全局一致的协调者（目前看这其实是比较现实的办法，功能简单，稳定性和性能应该能做很多优化，当然具体看你场景能否接受）

@Cola98 那就把展示的服务/ui 分开，sidecar 只分析和采集就好了，你 redis 实例 也不能保证就一个吧

分析工具就作为 sidecar 和 statefulset 一起呗，干嘛一定要部署成 deployment

软件防串改本来就是个很复杂的问题，各种方案无非是，是用更高可信的代码来验证其他代码的可信性，收窄代码保护的范围，比如你可以这样:

你可以用一个 自己的 loader(只是一个说法不一定是 ClassLoader ） 来加载 jar 和 class ，通过签名来保证加载代码可信，
这样就能把对抗的点收窄到 这个 loader 里，如果你用 native code ，一些传统的保护方案也能用了，比如 vmp 之类的

当然这样也只是提高了成本而已，你还可以更近一步，把信任继续往前推，比如依靠 os 或者 硬件提供的功能来实现，这就是可信计算搞的那堆东西了

再看了一遍描述，好像是同一台服务的两个地址，server bind 成 intranet 了而已？
iptable 能搞定