首先，114 不属于电信，而且，以前在使用的过程中，发现 114 有劫持的嫌疑，推荐使用阿里或者 dnspod 的。其实运营商在这方面属于有节操，一般劫持也只会推送自己公司的广告

@rokeyzki 厉害厉害

MS 系的肯定是 windows 开发爽，毕竟还有宇宙最强的 VS 存在。主攻*nix 系的话，肯定走回*nix 或者 mac 舒服，如果加上界面、字体、使用体验等等因素，mac 成为开发者(主要是*nix 系)热衷的机器就不是没有道理了。

@newtype0092 其实脚本也是一样的，set 操作的实现类 dict，对于 python 来说其实也是空间换时间，只不过语言隐藏了很多细节而已

一般情况下，工作的技术难度有限，很难谈得上技术壁垒，问题在于别人为你解答问题是需要时间成本的，如果你先去百度或者 google 或者看书研究一下，对于自己还无法理解的部分再与人沟通，我相信有很多同道中人是愿意一起研讨的，相反，什么都没去了解，就想人家给你传道解惑，那也太不把别人的时间当回事了

1.5 个月这个需求 50w 偏高一点但不过分，拉长周期可以便宜一点，不过 1.5 个月的时间应该赶不上，说 5w 和 5k 的敢情是来捣乱的，单单前期调研协调后期测试补 bug 的时间都不止 1.5 个月

推荐 siege 和 wrk 分别测试一下

@cevincheung 这个要看你多 master 的配置方式，比如说主动-被动模式下的双主不存在这个问题，这种模式下其实就相当于热备，如果是主动-主动模式的就会出现问题了，同时允许多个 master 写入是件很高风险的事情

1. 部分 rmdbs/nosql 提供 insert...update...语句，例如 mysql 的 insert..on duplicate key update 或者 postgresql 的 insert...on conflict update 都支持类似的方案，插入时重复时更新或者忽略
2. 触发器或者存储过程解决

语言缺陷少，工程化程度极高，抗队友坑的能力极强，有很不错的性能，跨平台特性稳定，在大型项目上，还没那个语言能像 Java 那么靠谱，Java 会挂绝对是一堆人在 YY

然而我最爱的依然是 Python :)

暂时没见过很多人推 centos ，每年的服务端 OS 统计，几乎都是 debian 系>rhel 系，用 centos 很大程度是由于社区、免费、开源；

两系的稳定性不相上下，至于包嘛，大家都是新旧不一，很难从包管理的新旧说明问题；

既然是 docker 部署，就没有太多生产环境问题。不想换到另一个系的原因，一方面是因为学习成本问题，虽然说大同小异，但其实深究，有很多设计理念还是不一致的，导致切换需要学习成本；在另一方面，多引入一种发行版，也会引起运维成本上升的问题。

如果 LZ 单纯作为测试机器，在生产环境部署能自行适配其他发行版，用啥都行

作为一个 rhel 系的长期用户，为 centos 正个名， centos7 的默认的内核已经跑上 3.10+， py 也已经跑上 2.7.x ；而且，作为测试机器，升级个内核也不需要多少顾虑嘛

线程安全这个问题不是 Java 独有的吧....

@baiyi 唉，主要是每次引战，非得要说那个是适合，那个不适合，抛开场景来啥扯一般很难有结论， restful 优雅，但 db 设计的三范式何尝不是？度是很重要

这个 topic 在 V2EX 已经引战 N 次...

1. 在经历多个前后端分离的坑之后，从结果上看，完全符合的 restful 规范风格的 api 是很难实现(应该说是实现起来反而很别扭)

2. 但是 restful 风格的 URL 、幂等性、授权对于设计基于 web 的 api 是很有指导意义的，所以最终在项目实施的时候，很多时候都会按照资源来划分 url ，但是不再使用 http 返回码以及 method 来表达资源的结果和用途，毕竟， API 文档还是要写的嘛

3. 其实，统一的 http post 在某种意义上很方便前端对 api 的封装

乱语：
其实前端打好 JS/CSS/HTML 基础是对的，往深走这点跑不掉；
其实 Angular/React 在组件也做得很好，的确适用于 SPA ，但是历史问题摆在那里，兼容性还有动画效果等坑太多，特别 ng 的 JS 动画效果性能慢得作死，远不如 JQ ；
不过做服务器界面开发， ng 真的可以快几条街；
路由不是必须的，但是状态管理却是必须的(其实前端的路由这两者没多大区别)；
前端的问题在于不用撕语言，可以撕框架了；
总结：兼听则明

1. WSGI 已经成为 Python Web 部署事实上的标准。无论是 mod_wsig 、 gunicorn 、 uwsgi 对 WSGI 的支持已经很完善；另一方面，几乎所有的 Python Web 框架都会对 WSGI 进行适配。
2. FastCGI 属于语言无关的 socket 通信，在使用 FastCGI 的时候，框架还是要先起一个 WSGIServer 服务，所以，即使 django 移除了 FastCGI 支持，仍然可以拿一个 WSGIServer 起 app ，然后 fastcgi_pass 到这...so ，写 WSGIServer 这事情就交给专人做吧，框架就该减减身子， django 已经向重型化发展了

实际上，如果考虑到通信双方的互信问题， RSA+SSL 才是更好的解决办法， RSA 的私钥是由通信双方各自保存，绝不能泄漏给第三方。缺点是 RSA 的消耗实在是太高了

暂时为止，不能。参考官方文档 Column 的 doc 属性说明『 doc – optional String that can be used by the ORM or similar to document attributes. This attribute does not render SQL comments (a future attribute ‘ comment ’ will achieve that).』

前端的一般是 200 ，后端接口互通才是 REST ，毕竟前端有很多坑，加上开发很参差，要全程 rest 不容易。再者，有时候 http 的错误码是不够用的，或者说，不知道用那个表示更好。在搞了很多个前后端分离的项目后，最后全部都妥协成 200 了