浏览器是没法解析 rtsp 的, 我目前用的是 hls 的流, 延迟 1-3s, 用的 H265, 在浏览器上使用 ffmpeg 的 wasm 解码 H265, 大部分浏览器都不支持直接播放 H265.

不明白你究竟想要做什么? 使用 ffmpeg 在客户端直接解码 rtsp 协议的流, 还是准备干嘛?

方式一: 有很多种办法可以保持事务一致性, 这个是数据库并发写入时保证一致性的基本操作了.
方式二: 并不会, 因为你这个结构就不可能有太多数据, 只要索引设计的正确, 不会有啥性能问题
书籍嘛: 我想到的有: 数据库概论(本科的教材), 高性能 MySQL, 数据库索引设计与优化, MongoDB 相关的设计原则, 对照一下关系数据库和 NoSQL 数据库的差异, 然后思考在 2 种模式下如何平衡性能 /一致性, 每一种选择都有自己的缺陷, 要根据你的业务场景寻求最佳 Schema. 有时候并不要求最佳, 甚至只需要有效就行. 等性能出了问题再去有针对的优化, 看的稍微远一点, 但不要太远.

@makelove 2 倍的 long, 16 字节, 打错了, mysql 用了 char32, 它应该是没提供原生的 uuid 支持

@makelove uuid 并不浪费内存, UUID 在很多数据库的实现中使用了 8 个字节, 也就是 2 倍 long 的长度, uuid 完全可以做到高效, 除非性能特别重要, 而且单个表数据极大, 否则选择 uuid 是一个很不错的选择, 性能是一个需要基准测试问题. 绝大部分系统的性能问题都不会因为你使用了 UUID 而导致. 反而我非常推荐使用 UUID 作为 id.

@erquiasz0825 因为按照分页查询时候, 数据会分散到不同的页, GUID 这种如果要作为主索引, 一定要支持自增, 否则插入 /查询都会有不小的性能损失. GUID 有自增的算法版本

非常麻烦, 我们的很多项目也是这个性质, 一个 core 分支, 每个人一个 dev 分支, 一个 main 分支(合并每个人的开发), X 个定制分支, 非常烦, 每次为 core 做 fix 或者 feat 都要重新 rebase, 然后重新测试. 一直没找到好办法. 但项目性质决定了, 赚的就是给客户定制软件的费用, 维护麻烦也是要做的.

@wdc63 没有这种数据结构, 不用找了

前后端不跨域的情况, 都直接使用相对地址发起 ajax 或追 fetch 请求就好了嘛

取决于你的前端是否和后端部在再同一个 IP 的同一个 Port 上.
也就是$protocal://host:port 这个部分只要前后端是一致的, 那么可以使用相对地址. 不过一些复杂的网站的 service 的 url 特别多, 肯定是需要写死在前端, 或追至少要写死一个 1 个获取其它地址的统一入口地址.
例如: Nginx 代理: 192.168.0.1:5001(API+vue public resources), 局域网直接使用局域网地址, 然后 Nginx 使用 https://host 访问, 所有 API 都是以相对地址请求: post: /api/app/token 这种, 没啥问题

@feller 一直使用 scp -r $dir $dist

用过 three.js, Unity3D 结论是效果都不够好. 需要优化的地方太多. 做的漂亮要看设计和美工. 做的顺滑就需要优化上下大力气. 我是没有耐心再搞这个玩意了.

去 github 上搜索, 基本上每个方向都有人做技能树. 但计算机领域实在有太多方向了, 人力有限, 也只能选择几个有限方向, 越是深入, 领域就越是细分. 但最基础也是最核心的, 就是 CS 考研需要考的哪几门.

@LeeReamond 我晚上回去打 log 看下各个地方的耗时, 我现在都没有跨网络, 本机测试延迟都是 1400ms, server, provider, render 都在本机.

2MB 的 base64 str(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换为 numpy, 然后转换为 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络传输 20MB, 大概需要 10s(香港到大陆). 我想想该怎么优化.

@LeeReamond 2MB 的 base65(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换未 numpy, 然后转换未 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络纯属 20MB, 都需要 10s(香港到大陆). 我想想该怎么优化.

@LeeReamond 没找到好的办法, 只能使用多进程, 然后使用 Queue 做数据通讯, 但真的很慢很慢. 你用过 mayavi 库吗? 是否有性能优化建议, 这个库启动非常耗时, 每次至少需要 3-10s, 每次同步的数据数据比较大 1-10MB, 然后还需要从 str->bytes->目标数据结构, 最终体验非常差.

另外, 对外在能考虑到的情况是不会抛出系统级别的异常的. 如果事前没有考虑到, 那么就让他直接奔溃. 由宿主层去考虑要怎么执行下一步操作.

主要要看你处于什么层次, 你做的这个层的消费者是谁, 如果你作为一个底层库, 要看错误是谁导致的, 如果是用户入参有问题, 我们就是抛出异常, 如果是内部的不受控的上下文依赖导致的问题, 也是直接抛给调用者, 如果是内部业务逻辑错误, 也直接抛给调用者. 如果是外部调用者(普通用户或第三方 API 调用者),那么就需要在外层统一处理一下. 主要是大部分错误就没法处理. 直接返回给调用者. 主要是看是逻辑错误还是其它. 说白了, 异常是一种偷懒的流程控制手段, 看你怎么用.