最后回复一下：

1. 南方（至少我们这）提车都会挑日子（习俗），虽然我也不太信这个，但是只有长辈懂，所以征求长辈的意见。这和妈宝扯不上半毛钱关系哈。

2. 征求亲妈意见是老婆先提出来的，我觉得这也是老婆对婆婆的尊重，并没有什么不妥。

各位意见我都虚心学习和借鉴，帖子到此打住，感谢各位的关心。

感谢楼上楼下的 v 友的建议。

统一回复一下：

1. 亲妈的说闲话的顾忌还是怕被亲戚借钱、借车之类的关系不好处理，这点在人情事故确实上很难处理，我也明白。因为工作原因，确实和家人沟通得比较少，下单前没和家人讨论也确实不应该。回头好好沟通一下。

2. 个人的经历不具参考性，比较难复制就不在这里给大家乱带路了，一个人从产品+设计+运营坚持一个项目十几年，之前一直负支出，这几年开始尝试变现。要总结就是：坚持自己的兴趣和信仰，现实一定不会亏待你的。

3. 关于 50w 的代步车在这边确实有些过。但是我和老婆都很喜欢那款车，其他各种其实都有试过很多，一是自己已经有七座 suv 了主要考虑轿车，二是想后续 8-10 年不用换车了，干脆一步到位。

综合以上，目前还是非常确定要坚持买。

真没人在 ns 上玩「上古卷轴·天际」？我龙裔不佛！

有个东西叫索引表

json 别编码试试：json_encode($data,320)

试试 Xavier
https://github.com/mdbs99/xavier

1. 关所有 log/binlog
2. batch insert
3. 多进 /线程
4. tmp 目录指 /dev/shm 目录
5. 上 ssd

插入速度取决于你的硬盘读写速度。
4e 问题不大

给个地址 让 v 友爬到你怀疑人生

电影检索核心其实还是降维的问题。

电影先降维到每一秒为截图，剔除掉相似度大的截图，存大盘鸡或 oss，然后转 simhash 之类的存检索库，求相似度应该能粗略解决一些需求。

假如一本电影 2 小时，截图 7200 张，滤重后假设 5000 张？算检索 100w 部电影最终也就降维到 50 亿张图片的 simhash 检索而已。

当然，图片特征识别应该是在检索降维中比较重要的一些细节等等，个人小团队要想做好这个引擎，应该有很长的路要走。

@AaronLiu00

🙏以及感谢各位，虽然和我想的差一点

不过已经按思路手撸了一个前后端版本，准备小范围实践下

之前已经有前人开源过图片生成

https://github.com/jklmnn/imagejs/

按说明处理过后，发现 chrome 安全检查已经屏蔽非 javascript header 执行 js 了，so 只能放弃…

P.S. 图片加 php / asp 代码早已经是皆知的事情了哈，那个不存在绕过文件头的问题，和我这个还不太一样

P.S. 图片压缩部分，我确认了一下，浏览器上 png 压缩率不是很高，一般图床也不会对 png 做特别处理，只要 png 数据不是特别多的情况下，效果应该还能接受，不过也要全面测试

@locoz 如果是存三方图床上的话，那还会有跨域问题...

楼主只考虑了正常请求，当你被 baiduspider/googlebot/bytesipder 等爬哭又不能禁的时候你就知道有多痛苦了，所以，这种讨论在我看来意义不大，该用带宽的时候你想省都省不了。（俺的站每天 2 亿请求）

同自己写，这玩意得自己分布式，记住单机检测是肯定不可信的，分发任务和执行任务环节都会可能出问题，多核机用 swoole 走多进程协程检测，检测几 w 个毫无压力，慢慢写，过程很 easy 的

@fluorinedog 感谢老哥指导，小弟受教~之前确实理解错了
不过我觉得可以通过控制每个 hll 桶内元素的数量去解决误差？
像类似于可能在 1w 或 10w 的数据集的时候误差比较小，
那么通可以过 id % 桶数量 找到对应 key 来减少误差，
个人想法哈，仅供讨论...

提供解决方案参考
对于重要的下载地址直接 rewrite
aaa.rar
可以重写为
aaa20191007.rar

根据更新频率自己安排时间颗粒度
保证用户下载的内容是最新的就行

语义化？ vuetify 了解一下

inc 和 dec 都需要额外处理高并发下一次购买多件的问题

@fluorinedog hll 要统计的时候直接把整型往里丢 数据涨了就代表集合里没有 没涨不就代表集合里没有么？

当然这不是原子操作，高并发下肯定有问题，主要是楼主也没有说要多大并发，只是要求毫秒级。