ssh 搞个端口转发不就是了，一条命令的事情

行是行，不过估计你需要自己写驱动，把 usb 注册成存储设备，接着还要搞定文件系统，现成的方案估计是没有了，这一堆搞完，真是。。所以还是好好用 smb 吧，反正一台电脑也不值钱

@Aouyu #37
@Xusually #38 前段时间密码锁电池没电了，然后惊讶的发现，当放了一个伪劣电池的时候，外接电源毛用没有，真了个是。。。

@ShuA1 电磁锁才是这样的，一般用电池的指纹锁都是电动锁，断电并不会开，而消防要求则是内部有物理把手可以直接拧开

60 帧 90 帧还是 120 帧事实上人眼根本分不出啥区别，流畅和这高刷新率也没啥关系，低刷新率人眼虽然分不出区别，但是长时间阅读还是有区别的，高刷新率会显著降低人眼疲劳，特别是长时间阅读，低刷新率眼睛都要瞎了

@reus #16 你确定？ go13 的时候写个死循环照样卡死其他 goroutine 啊，啥时候改了抢占式了

你知道一般现在就算小型系统都能一天百万级别异步任务请求了，所以一看到这个请求记录还有通过 http 请求就。。。你这是玩具吧，如果定位于人工管理的自动化作业系统，那么分布式部署的意义在哪

@SeanChense #59 但是吧也证明你这个策略是抵御风险十分小的策略，而且这种几天涨这么多，很不稳定，最终赚的概率很低

顺便说所谓长线价值投资，大户大机构咱不说了，对于小散户来说吧个人觉得很大程度上是各策略中最容易被人理解、最容易实践、需要信息最少、需要踩坑最少、心理负担最小的策略了吧，其靠谱程度还是个人谨慎对之吧，而且交易量低也必然代表你踩坑效率低，对大盘感知低，更倾向用以往或公开观察数据确定交易，风险还挺高的，所谓事有两面，交易频次高低各有风险，怎么把握还挺难的，还是建议谨慎再谨慎

@Perry #55 而且这种情况 8 成很可能最终折进去啊

最近几天的收益率完成了整年的收益率。。。。还是要淡定一些，能否完成落袋才是更大挑战，而且去年今年这行情，算是不错了，属于只要胆子大都很少亏的吧

还有上面说啥基金不基金的，去年下半年到今年上半年基金收益率普遍创记录了，闭着眼买都能赚个 10%，还是别心太高了

相机又不是随时开着的，你们以为 apple 会傻叉到这么出天际么，有点智商的都不会这么干，有点脑子的也不会信这种没理由的话吧，最不济也是相机设个高优先级打开的时候清理就是了，更大内存可是实打实要花钱的啊，你同意 apple 估计都觉得你是傻叉

各种免费 wifi，路由器，手机电脑内的木马软件，各种防火墙，各种骨干网节点，都能看到啊，网页的还有各种劫持，现在看来估计是各种免费 wifi 和路由器记录的日志危害最大了，有 https 好一些

@guokeke #30 开到 100 倍杠杆，分分钟尝试飞到天际然后突发爆仓的刺激人生么

事实上无论股市、币市、期货风险的逻辑都是一样的啊，就是赚和亏损造成的深度不一样，千万不要低估自己的恐惧心里与贪婪心里


@manami #8 其实资金弄少一点，保证不大伤，然后多被爆几次仓你就淡定多了，哈哈哈

@li24361 #11 嗯，不一样

假设你把 dingding 的域名在 hosts 里绑定到了 192.168.10.2 而 b 机器的 ip 是 10.10.10.3

iptables -t nat -A OUTPUT -d 192.168.10.2/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.10.10.3:8008

在 a 上设置这条 ip，那么就可以把访问 dingding 80 端口的流量都转发到 b 机器的 8008 端口上，然后再在 b 机器上设置把 8088 端口的流量都转发到真正的钉钉服务器去就行了

这个的好处是只有服务器能配置 iptables，无视程序自身是否支持代理都能正常使用，非常方便

可以在 a 上用 hosts 为 dingding 的域名设置一个 ip，然后用 iptables 为这个 ip 设置一个重定向到 b，接着在 b 上配置一个端口转发到真正的 dingding 服务器就好了

用重定向的用意是为了把 dingding 请求的 80 或 443 端口流量转发到一个非 80 或 443 端口的 b 上，这样 b 上就能直接通过端口设置端口转发了，a 通过 hosts 设置的这个 ip 存不存在都不重要，反正都要被 iptables 重定向修改

这个问题在于，在复杂系统中虽然分布式事务无法避免，但是更多情况应该是独立流程更稳定而不是用分布式事务，而且独立流程耦合度更低、重入更容易、解决异常也会更简单更快

比如你上面提到电商下单扣款的问题，实际上这是两个流程，第一个是用户下单，第二是用户付款，用户下单应该由订单中心完成，但是余额扣款应该统一和支付中心来封装成统一的支付过程来完成，支付流水单和余额应该在同一个库中，剩下就是微信支付宝怎么走付款流程流程，这个也应该怎么走

分布式事务一旦出异常很多时候是未知且难以追溯的，要想尽可能降低出异常的概率就要求更稳定环境和协议复杂度，对于相对独立小流程拆解显然可以降低对环境的依赖，出异常可能更高但是出的异常大多都是可预期的，从外部系统补偿解决相对简单很多