我们家一般选择 解析到 ccav

http://blog.sina.com.cn/s/blog_9c079b040102w5cr.html Google 黑板报博客有介绍， Google 的 Logo 向来 gay gay 的。辣么大一个 G 字

fastjson 有坑 需要规避

不知道讨论这么久 得出了什么建设性的结论。芯片＋磁条终究是最合适的过渡方案。虽然不能保证 100 安全，但是可行的升级方案。如果一定要找空子的话，个人建议就不要把你的卡带出门了。这么担心被 copy 磁条，就直接用支付宝之类的吧。

斗鱼可以户外的。有相关解决方案。你可以联系下斗鱼。

可怜的娃。。。下次注意下呗

支付宝用保险来转移安全风险么？ 被盗或者大规模就让警方介入调查，让保险公司赔偿损失。
感觉像某些银行网银一样，有些安全隐患很明显，但没人敢利用，因为立马会查水表什么的。

如果仅仅是搜索这一次层面的 增量更新，其实可以ORM层发送MQ，然后推送更新到搜索服务器上。不过走 Bin log 应用逻辑上是能优雅很多。 除了搜索更新外，缓存推送更新，各种事件的触发也能从 Bin log 走。PO 主加油。。

员工泄露的可能性 不大。个人还是比较信任团队的
@auzeonfung

@zur13l 渗透可能性不大，那台 iMac 上登录过 几乎所有的 服务器。但只有为了方便查询 MySQL 的跳板数据库被登录了。其他服务器没有，如果是渗透的应该所有服务器都会进行被登录的，毕竟拿到私钥外还要知道什么服务器可用，必然会测试其他服务器的联通性等等。

至于内网安全的话，谢谢提醒。是有开过屏幕共享这样的。




@cuebyte
ssh 那边限制了，只允许私钥登录。auth.log 也有异地登录的日志。

@rio 其他软件的话，就剩迅雷 pycharm。sourcetree ，keka。然后就没了。...其他有key的服务器没有被登陆过，只有用ssh代理访问内网资源的跳板服务器被异地登录了。...

@maxsec
昨晚 初判是 私钥泄露的时候 就紧急处理了，服务器上相关的 authorized_key 都处理掉了...
现在抹掉硬盘，重装系统中。

http://resources.arcgis.com/en/help/rest/apiref/ 拿去。

轨迹球？

@mengzhuo 俺们的数据超级扁平，所以仅仅量大。

那个测试结果的话...不太清楚呢

@mengzhuo 这个你就不用担心了，内存中的数据如果很久没使用就会释放了，mongodb的内存管理都推给系统来做了。至于什么时候释放看 系统自己了。在内存中的基本都是热数据，只要内存中能放下 热数据和索引就足够了。
之前项目是亿级的记录，全部数据百G，内存常驻热数据9G左右。
然后 前面提到到的 30ms 要求。建议根据各个链路的日志信息监控下各个流程的消耗 再来针对性优化。直接就到数据库层优化有点早了。如果是mongodb在拖后腿的话，大概消耗了多久？什么操作？读取还是写入。

对了，额外说下 mongodb 的写性能一般，相对于轻松上万 qps 的读来说，而且写会影响读性能。使用主从来实现简单的读写分离也是 题主 可以考虑优化的选项之一。

@benjiam 微信好像 有朋友数量上限，然后Push几百人的话，应该是 MQ 之类的推送 ID。然后把 ID 加入个人时间轴，至于数据热点的话，这个 ID 对象本身内容，可以通过基础的跨机房通信渠道同步推送 什么的。

至于微博那样的几万粉丝用户的话，就是采用 pull 了。本身在关注操作的时候就有区分数据获取方式了。 朋友数量大于一定的用户（这部分用户总数并不会很大，参考 28 原则 ）的更新就只提交到公告板类似的区域。其他用户获取新时间轴的时候去这个公告板获取数据来填充自己的时间轴。

@dcoder Kafka, Spark, Hadoop 这些啊。的确是通用的呢。我是Java转Python的，也许入门不久，总觉得python 在这方面少了点什么。。。最近在纠结Python的RPC解决方案

至于 DRF 和APP的兼容性来说，DRF和你提到的tastypie一样。Django+tastypie和 Django＋DRF类似选择SpringMVC还是Struct的区别。 都属于辅助性质的Framework，层级上属于project的。对其他一个项目里的没有用 DRF的App基本没有影响。不过 DRF和tastypie 应该不能兼容。

DRF有些不好的是，一些Django东西在DRF里不能用，比如 @csrf_exmpt这个注解就不能直接在ModelViews上标，需要一些Hack操作。

个人比较建议去看看DRF，如果他的 REST 风格能满足复杂的需求的前提 可以考虑一用。毕竟是一个比较成熟的框架了。

首先 冷热数据分离 用shard 来做并不合理。shard，一般是用来处理单机内存，不足以放下 MongoDB的热数据（含索引）的时候才采用的。如果是用户基础数据的话，并不大量吧？冷数据系统会自动清出内存的。

关于题主的真实需求是啥？让用户热数据在好的机子上，来加快用户相关接口的访问速度还是啥？