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

数据量小 shell 各种指令组合下就能查询过滤够用了吧，而且读写都是顺序效率也不低，方便又简单，哪都能用，根本不用想那么多吧，要是你一天写十几 G，几十 G，甚至几百 G 日志，纯文本顺序写入都够作死了，sqllite 真的是作死中的作死啊，如果这时候你还能用 sql 查出来那真的是见了个鬼了

其实这些都不是啥大问题，边缘反光才是大问题，靠窗啥的看手机感觉眼睛都要瞎了

虽然 ip nat 这个问题解决了，但是受防火墙限制，各宽带里边的 v6 也不能直直接连接吧，而且 p2p 这种东西，tcp 也没看出有啥好处啊

tinc 的话，没公网 ip 也可以，有公网 ip 的话，随便搞个 vpn 就能搞定了，太多方法了

曾经房间有好多只老鼠，晚上跑来跑去吵的都快神经质了，后来几乎铺满整个房间粘鼠板，抓到了 11 只之后，似乎从此安静了。。所以给你的建议是出租屋的话搬家吧

就现在内容饱和情况下，如果做内容整合多搞搞你就会发现做这个的比自己想象的多多了，自产高质量内容的话其实无关要不要自己搞个小程序，建议最好有个小创意做小众圈子的，这个世界的麻烦在于任何看起来很简单的事其实都有想不到多的人尝试过了，进去就会发现水咋那么深，所以切莫轻易畏惧放弃但也不能轻视困难

可以去看看翼王的视频，之前看到他组 40G 网络，nas 复制 2GB 每秒，快到飞起，但是都是钱啊，穷人玩不起。。

smb 复制文件性能似乎确实比 ftp 下载弱一些，但以现在机器性能跑满千兆也没啥问题，速度不及也可能网络磁盘啥的都会这样，网吧怎么着也得是企业级交换机，交换机和 nas 怎么也得是万兆网的吧，磁盘也许也不是普通的，你要是不心疼钱弄出来妥妥的

这类型的小程序并不复杂，你多点时间很快也就做出来了，核心还是内容，低信息价值的内容同质化严重，推广很难的，高信息价值的内容难点也不在小程序或者技术方面，但是现在是低信息价值内容泛滥但是又算法为王时代，如果你能想出更有意思或者更好玩的算法的话，似乎也不是不能玩一下的吧

另有想法并且是行动派是个好品质！

@DamonLin #10 怎么说人家也是有点想法的行动派，不管行不行，别没事打击人家好吧。。

@abczise #8 你搞个本地局域网试试就知道了啊，本来就很快，但是北京到上海一个来回物理延迟都 30-40ms 延迟了，局域网基本 1ms 一下，挂在远程盘到本地需要来回交换文件元信息，延迟影响很大，要是能无视物理限制那你就牛叉了

一看有点高端啊，但是本科的话顺利毕业最重要，还是不要选那么高端的吧，当时毕设就是一开始还想选个有意思有难度的没选到搞了个自己觉得应该很简单的，结果还踩了不少坑差点把自己坑了。。

https://github.com/snower/forsun

之前做过一个服务，高性能，用资源 ID 创建任务，到时发起动作，可以是 shell、http 请求、mysql 语句、redis 命令，可以使用 redis 持久化存储，不拍丢失，特别适合订单超时支付取消、配送订单超时之类的人物

当然也可也自己编写执行器扩展接入自己的项目里

从现实来说，交易只有记账，没有余额账户一说，当前账户余额只是记账的统计快捷缓存结果，消费或者收入就是记账过程，余额变不变无关紧要，所以任何时候只能信任记账流水，记账统计加和与余额不等，那肯定就是余额错了啊，注意处理好精度损失啥的问题，你这是只扣余额不记账么？那么你要被自己坑死了。。

@redford42 #1 不要忘了现在 cpu 都是多核超线程的，就算是高 cpu 的计算用多性能也可以充分多核加速

@freshgoose #25 因为大多数情况下，性能强真没啥用，工具多，文档好，开发快，部署维护方便才是更重要的，有几个公司需要跑几万几十万并发的，真有加个几百台机器不香么

等你业务都已经做到堆机器 django 性能还是不够的时候，用不用 django 你已经无所谓了，所以 700 又咋滴很高了，这个世界也还没几个需要用的 700 每秒呢，大多数情况下相比运行性能业务性能更重要

@refresh #12 你举这个例子很不恰当，完全不符合现实情况，从现实来说，交易流水完全基于现实动作在时间维度产生，因为时间不可逆转，所以使资产或者余额发生变化的交易流水同样不可能存在需要修改的情况

如果因为某些情况之前的交易存在歧义或者错误而发送交易纠纷解决，那么既然现实已经在新的时间维度上真实发生了一件交易纠正的行为，那么就应该真实的产生一条新的交易记录从而使余额或者资产发生变更，修改原交易记录是极其不恰当而且也不符合现实的

关于系统异常导致的问题，下一条的交易变更应该完全基于上一条已提交完结的事务产生，在此种情况下不应该存在中间某条是错的情况