@hefengwqz .... 还以为啥呢，这种需求 j4125 ，n100 ，n95 ，自组 itx 小主机+万兆网卡就行了...

你是想数据包转发走硬件转发，还要能针对数据包做处理的对吧？ FPGA 了解一下

@leonme 昂达 itx h610 我也有，铭瑄的 itx h610 2lan 双网口我也有... 我建议用铭瑄的 h610 2lan 双网口 。matx 和 atx 不清楚

先说我半年前的配置 J4125 + 8g
再说说我现在的配置
12300t
16g
万兆网卡+poe

n5105 的 cpu 性能太弱，

使用 alist 映射各种云盘资源
使用 transmission 下载网络资源

不说宽带范围和使用范围默认你千兆下载满速，当你满速下载的时候 你的 cpu 已经是 100%了，这个时候如果你做点其他的事情 那么基本上就不够用了，这种 all in boom ，要么不搞，要搞还是搞一个好一点的 cpu ，n5105 的发热也比较大，不要扯啥省电，开个空调一天哪个不比多十几 w 耗电大。

n5105 这点性能不够，n100 也不够，上低压 u 吧。上面的性能真一点都不够看，说 n5105 够的了 基本上没跑过下载和大应用(流量,耗 cpu ，gpu)服务。


12300t 我满速下载+上传 基本上 cpu 占用在 70%左右。再直通 gpu 给 jellyfin 没啥压力。

整体功耗比我之前的 j4125 多了 30w 的样子，另一个 并不是长时间都是高负载跑，但是要高负载跑的时候 你正好有其他的服务 比如旁路由 就会影响你的浏览体验。

n5105 玩玩可以，这么多服务

可以容忍一定程度的数据丢失和**系统崩溃** -要做到这一点可不容易

盲猜 modal 弹窗先渲染了，但是内部可能有一些逻辑做了一些处理，导致 modal 先出来，但是 container 没渲染出来。。 没时间搞环境 可以从 settimeout(func,0)开始试试。

@relsoul 补充一点，建议把防止改为 如何提高恶意用户刷接口的成本 这样的话会好理解一点。

1. wasm 有浏览器兼容性问题，外加一点点性能问题
2. 恶意用户可以不了解你的加密规则，只需要拿到加密后的结果即可。
3. 建议在 WAF 层做限流拦截处理。

折腾过的人告诉你，买两台电脑，或者两台笔记本。

没人回答来简单答答....

jwt 多方便啊，不用中心态维护，直接做校签就行。（当然你也可以用 redis 来维护 jwt ）

只要微服务的配置中心的密钥一致，那么无论什么微服务都不用依赖 redis ，直接本地做校签，减少架构依赖性。不过某种意义上来说 jwt 也是一种 session ，去中心化的 session 。

简单答答

mysql 和 pg 的定位差不多，不过 mysql 在国内的流行程度和成熟程度远远大于 pg 。从用法来说 pg 的支持程度要大于 mysql 的。所以如果抛开历史因素不谈 现在选择 sql 的话 pg 是首选，但是就像之前有位老哥说的 从 mysql 迁移到 pg ，发现 sql 不兼容，开发人员写了一些 mysql 特定的 sql... 所以从开发的知识体系来说，国内 mysql 还是老大哥。

ck 没用过，不能回答。
es 也只简单用过，我的定义是文本搜索，其他等大佬们补充。

mongodb 用的还算多，不过也仅停留在业务层，mongodb+nodejs 是前几年开发的标配了，之前的版本不支持事务注定了成为非标准化格式存储库，现在版本支持后用 mongodb 做主流程的也挺多（交易这块）。mongodb 的性能要好于 sql （不绝对），并且横向扩展性也好（集群扩展），由于 bjson 的形式 可以成为非成型业务的快速开发首选，node （快+json 天生友好），mongodb （ bjson 的形式）。

nginx proxy manager

简体中文输入法，罪魁祸首

openmediavault

启动后如何避免再次出现攻击行为？停止哪些服务？或者防火墙只允许 ssh 端口（以前一直是 ftp 方式连 ssh 端口传文件）？
有什么排查的思路？（能不重装当然最好）
---
之前一台 digitalocean 主机被 hack 的人告诉你
1. mongodb ，redis ，mysql 当时部署在主机上，估计是对外网访问 并且是弱口令 从这层入侵的
2. gogs,某些 php 代码 等 web 服务等 0day 导致的，这个得你自己排查
3. 套 cf 可以解决一部分问题，但不完全
4. 建议上 docker 部署 隔离
5. 随机生成密码，不要自己想密码

@lysS cf business 用户 告诉你 会，针对国内访问不要套 cf 。不过 cf 的 waf 很屌，所以看你怎么取舍了。

标题即答案，赶紧备份+还原系统吧。

@Greenm work work

如果是小项目不要走 websocket ，如果要走 可以试试 socket.io ，我的建议是 直接前端轮询就行（ 1s ），减少前后端的心智负担。所有的计算后端放 redis 处理。后端做延迟/定时任务更新 redis 的 key 即可。拍卖完成后落 db 。
如果是大型项目估计也不用我说 架构层应该已经评估了时间与开发量得出了解决方案。