@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。。

如果这样的话，预计是大概率要折，难不成以你为国家为了好看会撑股市？想太多了，兄弟

直接买个支持 raid 的硬盘箱呗，挂在软路由上，smb 或者 nfs 共享下就解决了，估计也能在软路由上做软 raid，这样的话只需要个硬盘箱了

@BingoXuan #17 他的意思的是单个 UDP 包，UDP 没有重排，所以应该是一次必须把整个 UDP 包都接收了，不能分成两次读取一个 UDP 包，跨 UDP 包当然不会有问题了

一二季度补贴 60 亿，强大补贴带来用户交易额增长超过补贴增长速度，亏损额有所降低，但是长远看似乎下定论还早

https://www.paycats.cn/

支付猫，之前看起来很不错的样子，但是也没用，不知道还活着不

Navicat 没有很明显麻烦的保存 apply 操作，直接生产环境确实感觉危险一下，哈哈哈哈

有句话叫技多不压身，担心用不到太多余，应该担心学不会或者时间精力不够那还差不多