@petelin #38 这不用想吧，多人协作中，至少各业务是分开的微服务组件，修改更新的至少不需要整体等着大半夜统一重启更新吧，单个项目结构更简单，新人来了熟悉难道不更快，反正你又不是大佬一来就负责所有业务
伸缩性更不用说了，那个服务性能不够了，再加几台机器就是了，多简单
业务适应性更新更不用说了，就现在这行情，上个月卖水果，这个月就可能想着做金融的，微服务化的至少你不用担心做新项目的时候还不知道哪把老项目改出 bug 来了吧，老的项目或者直接废弃或者只要不挂扔在那不管就是了，这还不比你单个复杂项目适应性更强？

微服务提高的是开发维护效率，伸缩性提高，业务快速变更适应性明显增强，运行效率必定是降低的，稳定性要求必定更复杂，这不用说啊

@dji38838c #12 我觉得以前收集的和隐私相关信息或许都不会威胁个人安全，但是个人生物信息就不一样了，那天万一泄露了，手机还可以换个新的，人脸你是要去整容么，看看现在手机号泄露满天飞的

而且感觉最近风向开始转了吧，毕竟融入生活太深了，看看谁会成这个出头鸟

@cest #6 就算以后会有大范围公用追踪系统，但也应该只有公安系统可以使用吧，普通企业并不能使用，不过这个其实也是严重不合理的，太危险了

@JCZ2MkKb5S8ZX9pq #4 这个比喻不合适吧，线下这样之所以是安全的是很多条件的，比如线下不借助现代科技手段几乎很难百分百想另外一个人完全传递我的信息，受现实限制，这个信息不会很快扩散至很大范围，在他遇到更多人或者时间变长的过程中会渐渐忘却我的信息，我觉得不安全时可以选择不在去让他忘却我或者改名、搬家等等，如果对方利用这些信息跟踪监视啥的我们是很容易发现并选择主动避开的

但是支付宝微信这样的线上大不一样吧，且不说百分百复制信息多容易，而且不管过多久这个信息任然存在，不管你到哪也任然存在，如果他有意滥用，你几乎不可能发现，这些都是很容易威胁个人安全的存在，谨慎使用时必须的吧

关于爬虫这个问题，所有爬取信息必须得到信息方许可这是强制要求啊，否则就是违法行为，这也不一样吧

我个人认为人脸数据使用应该和上传时预先告知或者和人常识使用范围一致，不得用于超出范围，使用时告知不应该被允许

@Jirajine #3 但是不管你 tos 怎么写，都不得违反当前法律法规，侵犯用户权益，否则你写的再怎么牛逼也没用啊

这样数据一致性和业务一致性都用数据库锁来保证这难道不是又是一个大坑？
如果好友申请时好友关系的一个状态，那么用数据库事务和唯一索引来保证不重复这没啥问题，但是既然你想分开好友申请和好友关系，那么这个业务一致性的要求，更应该用外部锁来保证业务流程准确是不是更好？数据库就应该简单高效准确的完成数据管理的问题，其他的都应该交给外部业务系统才是

关于用 redis 锁的问题，如果你业务量大，这不算啥吧，如果本来就没几个人用，这还想个啥子，这种同时发两个请求的极低概率问题，遇到本来就微乎其微，去他丫的了

python 协程本来就是 future 调用链，单线程又是线程安全的，想实现 go 的 channel 逻辑很简单吧
用两个变量，一个数组一个 await 等待对象，处理协程运行的时候判断下数组为空则创建一个 future 对象赋值给 await，然后等待 await 对象激活，数据协程则先往数据组中存入数据，判断下 await 对象存在且未激活就激活 await 对象，这时候处理协程就返回开始运行，取出数组数据处理就完了

贵重贵重，不重怎么能贵呢，产家如此想

@v2hh #9 平台的支出不就是用户收入么？所以应该是没有平台的表，只有用户的收支表，结余就是平台亏损或者盈利，这种情况下，余额应该是流水账加和得到的

再抽象一点来说，整个业务有一个收支总账，和平台相关还是和用户相关没有直接关系，把记录财务流水账的表和记录业务场景的订单表分开，业务流程驱动订单变更，订单完结产生财务流水，订单流程异常没有产生正常财务记账则无效，这种情况下应该走业务相关的异常订单处理来纠正，财务只应该和财务记账相关

@phantomzz #13 如果你说的是操作系统那个可重入锁的话，认真说这真是个很不严谨且偷懒的设计，web 这种场景中更不应该出现，难道你只加锁不解锁的么，需要啥重入

而且你这给出建议不考虑实际场景啊，大多数情况下，加个锁增加的 io 多还是队列异步中后台一大串 io 多，还不说维护复杂性在那呢，大多数场景下，加锁加直接该数据库库存是最容易实现最容易维护最容易稳定的方案了，能在这种情况下用满数据库 IO 的都已经是很高销售额了

感觉理解是不是有偏差，这里应该不是查出所有主键通过主键再去查询数据，正确的意思应该是索引不包含实际数据，只有主键信息，通过主键才能在真实的数据文件中读取出数据，这么设计出于提高性能目的，比如改表结构的时候，数据文件修改了，但是主键不变，此时无需重建索引，其他的比如可变类型修改超出原是长度需要挪动数据位置的时候也无需重建索引

@phantomzz #10 先加判断超过了，然后下单失败再减下来？
如果是做成锁的话，本来就不可重入吧，什么时候锁也可以重入了

楼主的问题是是不是商品一直在卖，担心中间有空闲再开卖有可能 redis key 不存在了，然后可能会超？其实感觉如果你用来做库存限制，那么 redis 就不应该是缓存，而应该是持久化数据库，所以 key 不应该超时，持久化要开，每次商品修改也要同步更新 redis 值才行吧，否则就做成分布式锁吧，库存的更新检查还是以数据库为主

什么远程医疗，远程手术，这也不是网络问题啊，否则我拉根光纤不是延迟更低网速更快？至少现在 5G 吹的使用场景没一个是和网络限制强相关的，没啥靠谱的，在一个因新技术使用而带来爆发性商业成长的时代已经结束，接下来是一段相对沉寂的积累期，有高潮必有低潮，这没啥不可承认的，妄想没有低潮的持续爆发性增长，你们都忘了那个 6000 点是牛市开始了么？但是苹果在产品和新技术的迭代选择上愈发保守这一点也是没法洗了，这是企业文化和战略的变化，那个引领时代的苹果已经没有了

你把 ftp 协议和 ftp 命令混淆了吧

这个应该就是网卡直通吧，主板 cpu 要支持才行的吧

其实为啥要把表主键和数据主键弄成一个，是不是表自身还是有个自增的 int 主键 ID 更好一些？数据再有个非线性可分布式的数据主键

https://www.influxdata.com/time-series-platform/telegraf/

一套挺简单的，nagios 真是有点复杂

@luozic #8 还有他说的是 1w 并发，不是 1wqps。。