@TIGERB #8 几百！！几千！！！你不是在逗？就这么点，要啥自行车

redis 原子操作扛不住，队列就能抗住这咋想的，虽然很多队列都能横向扩展到数百万写，但是写完了你就不需要处理了么，如果说队列只是削峰，那么异步 io 加 redis 就完了，想那么多有的没的干个啥

@clearCode0915 #22 大家都去了那就都完了，就算银行免除你债务了你不用还款了，你肯定也失业了，作死那就只能大家一起死，看看日本之前，瞎加息降息

从数十年长度看，经济总量越来越大，中国 gpd 增长率再降低是肯定的，现代经济都是经济总量增长必然伴着总债务增长，所以利息继续降低很可能，否则光是还利息都要私人了，美日欧现在就是这么个意思，但是想着一两年内突然降低几个点就别瞎想了，这不是给你减债务，这是让你自杀，所以吧个人认为如果你还款周期十年二十年以上甚至更长，跟随 LPR 动态利率是更有利的，当然这不是一个短期的事情

@edius #2 想太多，天量债务总额情况下，直接降两个点是想死啊

id 的话，感觉有顺序的更好一点吧，空间的感觉无所谓吧，反正内存磁盘也不值钱

定时任务麻烦的问题核心应该是大多数定时都是通过分钟级以上时间轮询，所以在秒级来看就会产生远超下单时的并发，但是如果能秒级定时，那么基本不可能超过下单时的并发处理量，而且吧下单时还需处理运费、优惠等等，库存处理也更复杂，本身来说取消订单就比下单更快，所以吧下单能抗住，取消扛不住的可能能几乎没有吧，再说吧定时触发后还要进入队列由异步任务处理，而异步处理任务的工作进程一般时固定的，那么并发基本就是固定的啊，什么队列抗不住这种问题除非你是淘宝拼多多，否则想这个完全是多余

顺便说无论下单或者取消都是一个流程问题，怎么能归结为一个 update sql 呢，订单撤回，优惠撤回，库存撤回，这难道不是一个流程么

下单需要及时响应，取消订单不需要啊，你真的并发太高，短时间一般任务无法处理完，晚一点也不算啥问题啊，所以不要想太多

https://github.com/snower/forsun

之前做过的一个定时的服务，用在订单取消还是很方便的，使用 redis 持久化存储稳定性性能也还可以，秒级定时，不会出现并发累积的问题，但是吧要是你这种动辄几万几十万并发的可能还是不行，但是真这么高订单的全中国的没几个吧，算是一种思路吧

还有吧，我看很多人都说向快递员收钱为啥还向用户收钱，可是这个明显不是只向谁收钱问题，而是收多少能大家都有好处的问题吧，快递员现在一单也就能拿一元上下，你说向他收一块这靠谱么，事实上大家可以查找一下各家做快递柜的没有一家是盈利的，全都亏损，丰巢算是做的不错了，也还是亏损，虽然这确实看起来是一件很简单的事了，但是其中隐藏成本也很多

事实上可以简单算下按一组快递柜 140 格口，满载率百分之 60，没件向快递员收 3 毛，一年下来也不大一万收入，而一二线城市物业租金普遍一年将近 5 千上下，加上设备折旧、电费、维护人工、短信流量各种加起来几乎没有盈利可能，这也是各家做快递柜普通倾向向用户收超时费的问题，如果能大幅度降低物业租金，我想应该是没有任何一家会直接向用户收钱的，关于物业租金为啥这么贵以及物业租金被用于干嘛了，这是一个问题

说起来丰巢向用户收钱已经比预计晚很多了，很大程度上是之前大家预计和快递公司可以深度合作，大幅节省快递公司末端配送成本，但现在看起来并不是很靠谱再加上菜鸟驿站崛起，现在他不收钱估计活着都很难了

@xy2020 #17 快递柜入住本来就是收了场地租金的，一二线城市一年 5 千上下，正因为如此加上电费和折旧维护成本后现在几乎都亏钱，物业无场地租金的话确实能盈利，也就不需要向用户收钱了

https://segmentfault.com/a/1190000022085297

专门的定时任务管理服务显然更方便啊

Connection 的默认连接参数和 pymysql 是一样的，autocommit 默认为 False，如果数据库全局配置 autocommit 也为 off 的话，是需要手动 commit 才能查询到新数据的啊

@XXXFX #4 啥？服务器不是有公网 ip 么？ ssh 登录上去设置 openvpn 就是了啊，要是没公网 ip 那还说啥，搞啥也不可能突破物理限制啊

openvpn 组内网，完

这不就是二进制字符串直接输出么？\x 打头后面两个数字的是不可见字符以 16 进制输出，O 这样的是可见字符，则是直接原始字符输出，没啥编码吧

@0gys #30 自己时小说主角的可能几乎为零的情况下，显然更多次尝试更能增大赢的概率，合理严格的风险管控是更为重要的，而且把在超大人口基数上承认比自己有资源也更聪明的人非常多也是必要的，作为普通人超过平均线的收益其实远比自己想的难得多，所以首先准备干啥就先干掉通过这一夜暴富的想法比较好，更冷静也能更有毅力，但是能抽身并清理就是最大成功了，毕竟年轻就是最大资本，时间就是最有价值的投资

复杂服务中一般不会这样用，更多会使用消息驱动异步任务执行，也就是数据和状态永远时往前的，和时间一致，反向传播状态和数据和时间逆向，状态管理会变得更加复杂且不稳定，难以提高横向扩展和并发性能，维护也难很多

简单系统当然无所谓了，简单的可以数据库轮询，zookeeper 的 watch，部分消息队列像 rabbitmq 也带有回执状态的也很容易实现

https://github.com/snower/slock.git

之前也用 golang 实现了一个性能不错的原子操作同步服务，可以实现一般系统中常用的 Lock 、Event 、Semaphore 语义，Java 多线程中的 wait 和 notify 机制其实就是 Event，而系统中实现的锁其实底层也是原子操作分装而来的，只不过加入了进程调度操作自动进入休眠和唤醒

@iConnect #8 微信能火是不要钱不是主要问题吧，和短信一样的话谁都可以给别人发消息的话，垃圾消息多到爆炸，肯定没啥用，不是的话重要的是产品和商业应用，移动运营商这水平恐怕做不出啥好用产品，说不定让反而微信更好用了，微信更强了

感觉每天写超过 1G 最好就用 elk，不要太方便，少的话还是纯文本 shell 过滤更方便吧，纯文本的记录也更容易应对未知错误导致写出奇奇怪怪的日志