你知道一般现在就算小型系统都能一天百万级别异步任务请求了，所以一看到这个请求记录还有通过 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 重定向修改

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

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

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

@fiveelementgid #14 一直都是设四条看起来就正常就没仔细看，似乎也没啥问题，其实吧公共 dns 几乎不会挂吧，8888 也不可能完全被墙，更可能改为在国内设置一个和 114 一样的节点，而且你可以 ping 一下看看，现在 8888 的节点似乎不是在国内就是在香港，已经在监管之下了，关于被污染，你设置两个也解决不了啊，因为被污染还是有正常返回的，所以其实并不会从第二个查询正常的，而且吧你用 8888 其实并不能解决被污染的问题，因为墙也会修改 8888 的返回结果和 114 一样，其实现在完全没必要用 8888，啥问题解决不了也不比 114 更权威，而且指不定啥时候延迟会比 114 高网络又慢了，通常情况下延迟似乎也要比 114 高一点

不用怀疑，本来就是这样的

@fiveelementgid #5 事实上你多设置几条也没事，并且我记得似乎系统能自动区分 ipv6 和 ipv4，通过 ipv6 解析的时候会自动使用设置的 ipv6 的地址，通过 ipv4 解析则会只使用设置的 ipv4 的地址，所以你可以设置两条 v4 两条 v6，这样 v6 和 v4 都能正常了，不用那么复杂吧

当然不能，这还用说么，ipv6 环境下 114.114.114.114 这个地址都不通，解析个锤子，ipv6 当然要用 ipv6 的 dns 了，8.8.4.4 和 114.114.114.114 都有对应的 ipv6 地址，找一下就行了

https://github.com/snower/forsun

之前做的一个定时服务，通过 key 指定定时任务，通过 key 随时可以修改，每个任务秒级定时，后端持久化用 redis 不担心丢失，已经稳定用在日百万级订单超时这样的任务处理，可以看看能不能满足

其实我也感觉有点跑偏了，好像不明确支持黑人平权就是歧视黑人的意思，过于强调平权就是在要求特权啊