• 我应该如何使用 git 呢 at 2014年01月21日

    每个人做的 feature 都单独开个分支啊,各自提交各自的,review 并测试 OK 后再合并到主干,使用 gitlab 或者 gerrit 之类工具系统

  • 10w 并发的服务器方案 at 2014年01月21日

    这个方案估计是做 PUSH 用的吧,我们一般要求三千万的并发,是指 socket 长连接,一般单台服务器可以支撑到 100-200W,你可以去搜下 mqtt 的开源解决方案,用 C 的或 Java 的都行,Java 一般用 Netty 来搞,可以支撑到 150W 左右 (8 核 16G 内存)

  • 令人苦恼的性能问题 at 2014年01月15日

    要做详细分析啊,看看瓶颈是在 rails 还是在数据库 i/o 上,rails 本身可以加缓存,数据库操作也是可以缓存的,不要直接读写数据库,先在内存操作,然后定时同步到数据库中。

  • 不错,看看去

  • 貌似现在已经好了

  • 关于算法, 我们该学什么? at 2014年01月13日

    牛啊,都搞明白了没。。。

  • #69 楼 @zhangjinzhu 不统一放票公平性何以体现?你是鼓励用户今年就订明年春节的票?总有一个开始的时间点吧,比如什么时间可以开始买 15 年春节的票;另外,每年铁路可能会增加或者变动车次,如果有变更了,但是你的订单已经提交过,就会很不爽;还有,这不是买机票,机票的用户群比较小众,火车票是所有社会层次的都会买,如果没有时间限制,大家也会很早前就开始订,但是可能到要走之前才发现需要变更行程或者退票,实际有迫切需求非常着急的人是买不到票的。不能为了简化技术门槛,而修改需求。

  • #67 楼 @zhangjinzhu 比如 9 点放票,一下 1000 万订单,你是要等收集到某个数量级订单后去捏合,还是计算时间,比如 5 分钟后开始捏合?捏合并且去数据库分配票时,肯定需要时间,这个过程中如果又有大量订单进入,是排队等下一次捏合怎么样?那用户买票基本上是一锤子买卖了,某车次订不上,等捏合处理完后才知道没订上,再换车次时,另外的车次可能都被卖没了。

  • #65 楼 @zhangjinzhu 你的意思是大家上午订票,订单后台“捏合”,下午运算完后再告诉你的订单是否成功预订?

  • 楼主看看实际系统的部分情况介绍吧,建议你去和淘宝技术团队 pk 一下:http://moni.iteye.com/blog/2001610

  • #55 楼 @zhangjinzhu http://coolshell.cn/articles/6470.html 这是个酷壳对早期 12306 的一个简单分析,可以参考一下;另外,我们都不了解铁路的网络系统架构、数据存储方式、各地的票务份额等等很多复杂的东西就来讨论,所以我说想的太简单了。就拿预约时间来说吧,怎么算,是提交时间还是服务器接收到的时间?车票的数据处理如何做的,是有几个大节点还是集中在某个数据中心?数据如何在高速变化中保持同步?每个不同地区的人订票指令到达时间是否有不同,靠近数据中心的是否更占便宜?数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)?订票后大量的支付请求各银行的支付网关是否能扛得住?可以想象一下,订票指令在开票时间几乎是同时触发的,这并发量不光是服务器能否受得了,当地带宽是否足够也是问题,有些无法访问不一定是服务器出问题了,可能是带宽的问题,运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配。。。等等吧,还有若干个问题都不是那么容易解决的;再简单的业务逻辑和流程,一旦碰到井喷式的并发量都会出问题的,不是光靠技术能解决的。比如,现在已经把不同类型车型分时段发放,本身就是分流的策略,当然还可以搞更多的分流。楼主说的第 1) 步就不好实现,这种类似网络攻击式订票请求,任何软硬件都很难说 100% 扛得住。。。

  • 想的太简单了呀。。。

  • 当然是了,你最好看看 App Store 能否打开,把该升级的都升级吧;如果还是有问题,建议重启进入 recovery 模式,修复下磁盘试试

  • 没问题,都很正常

  • :thumbsup:

  • 我面试的时候,算法问题可以通过思路考察,不一定要求写出完善的代码;但是肯定有写代码的考查题,也要考察思路、基本功、代码风格、习惯等等,其中最关健的还是找一些实际场景或者问题问一下候选人的思路,看看他会如何解决相关问题,并且是否能分析出该解决方案的优缺点和改进方向,顺便了解下沟通能力、表达能力、耐心等等,如果有不错的还会考察更多,比如团队合作、职业规划、文化适应性等,甚至有时候还是需要看看情商等,工程师也是需要有情商的。。。

  • 看到了这个文章适合说明 rails 适合的场合:http://www.iteye.com/news/28641-technology-stack-choice

  • 其实我喜欢的网站架构是 API+ 前端方式,这里的前端包括 (HTML5/CSS3/JS) 和 Android/iOS 客户端等,让 View 部分完全和业务分离,技术和物理上都分离。。。

  • 应该再增加些锻炼

  • 请教 Ruby 2.1.0 升级问题 at 2013年12月31日

    rvm 可以用 sudo,也可以不用 sudo 呀,看你的需要了

  • 请教 Ruby 2.1.0 升级问题 at 2013年12月30日

    顺便请教小,rbenv 相对 rvm 有啥优势呢?我一般都是 rvm,升级超简单

  • 需要过滤一下内容,不是热度高就一定好。。。想要话题热还是干活多,确实需要个平衡点,要不就没特色了

  • @bydmm 我同意楼主的观点。说实话,比较大的复杂的系统光一个 rails 是搞不定的,结合了多种不同技术和框架后效果会好很多,并不一定要彻底抛弃 rails,只不过角色会变化,从一个完整系统变成了大系统的一个小模块。

  • #3 楼 @bydmm 你说的也没错,不过类似于 CMS 和统计系统的展现等 WEB 项目,挺适合用 rails 的,一个是需求变化快,另外,也确实需要效率来弥补人员不足。总之,性能要求不高但需要快速开发的 WEB 项目才能发挥 rails 的威力!

  • 个人认为,rails 的适应场合有:1) 小团队创业,快速实现; 2) 对性能要求不高但是需要快速开发的系统,比如公司内部系统,如 JIRA 之类型的;3) 测试脚本。当然,一些高性能、功能复杂的系统更需要松耦合的设计,每个模块越简单越好,sinatra 之类的框架可以胜任一些工作,rails 有点太臃肿了。很多大公司也在用 rails,或者通过多种技术结合,好的架构来达到不错的性能,或者用来做些内部系统,比如 OA 之类。其实很多情况下,瓶颈在架构设计,而 rails 集成了太多东西,过于臃肿,不利于优化架构,除非砍掉 rails,换成 sinatra 之类轻量级的。

  • 搞不定内容就很麻烦呀

  • 《架构腐化之谜》随想 at 2013年12月30日

    #10 楼 @bhuztez 因为垄断了所以会难搞,因为供远远小于需求,所以会难搞,可以看看这个 http://coolshell.cn/articles/6470.html 搞好一个最大的卖票网站远比你想象的复杂,高并发会让所有简单的东西变得超级复杂

  • 《架构腐化之谜》随想 at 2013年12月29日

    这个文章很不错,适合大的长期项目的技术主管来学习一下;另外,看到这个文章让我想起来马云曾经说过的一句话,大意就是:现在的阿里集团没法管理,因为他的管理能力可以管理的团队大小是有限的,那怎么办?拆!搞成一个个小公司或者小事业部。