※ 引述《chan15 (ChaN)》之铭言： : 各位好，自我介绍一下，我写 PHP 大概七八年了，coding 部份有按照 psr : SOLID 设计模式，用 composer 管理套件，git 大部分常用的都会用 : 框架的话 Codeigniter、Laravel 都算熟，会写测试 : JavaScript、jQuery 都还可以，会自己写 plugin 来用 : js 写到 es6 用 webpack + babel 编译，玩过一下 vue.js : 写过商城、金流、彩票游戏 : 加分部份 : 1. 会写一些 shell script，Linux 部份 ubuntu centos 基本指令都可以 : 有玩 vagrant 跟 docker : 2. MySQL 基本指令，设定权限、CRUD 那些没问题，当然一些复杂的 join 也写过 : 但那种东西基本上应该要透过资料表设计排除 : 3. 会写一点 node.js 用过 express 架过 api server : 4. 会写一点 python 用过 flask 架过 api server : 大致上重点履历说明如上，当然履历上会放作品等更细的内容 : 我要说的是，一般徵所谓的徵 PHPer 的主管应该大致知道底限或者是极限在那才是 : 但从去年到现在，有去聊天面试的部份公司，精确的话来说八间里面有三间有问到类似的问题 : 让我有点无所适从，不过也怀疑是不是真的必须去加强这块，所以上来请益 : 他们问的问题是，要怎麽开发网页可以承担百万人同时在线，或每秒百万的写入 : 我的回答是，我没有过这样的经验，我待过得公司有超过万人规模的这种东西都是分开处理的 : 有 SI 会做规划，PHPer 确保程式不会造成延宕或出错，该进 cache 的进 cache : 一般来说 op 那边会透过硬体跟系统的架设去消化这件事，具体高流量每秒写入资料库的规划我们根本碰不到 : 就连我去问公司负责金流後端开发的答案也差不多，用机器、用集群、用缓存去档 : 但面试者会说在 PHP 这边也会有相对应的方式，硬体也有办不到的事 : 上一个面试者还说 MySQL 一秒只支援几百笔写入，所以你们要想办法 : 这几间公司的共通点就是，新创、c2c、都说自己是大数据，薪水大概落在 5-6 万 : 想在这边请益各位是不是後端要想办法切入这一块，是的话该怎麽切入 是我就把他们给当死。 https://zh.wikipedia.org/wiki/CAP定理 CAP定理，无法同时满足三者，至多选择两者。 关於服务人数，如果是专门看数字的老板，可以原谅，但是要导正观念。 如果是工程师主管，那就是Google指名不要主管的那种主管。 如果是工程师，那就是不知道自己在做什麽的工程师。 服务本身若重视一致性，可用性，那必然牺牲分区容错性。 反之选择任一两者，第三者必然被牺牲。 所以要看服务性质。 交易类型的服务，重视一致性，因此提昇它到所谓的百万人数的方法 跟重视可容错性的提昇方法肯定不同。 所以光会问百万人有什麽用，若数据一致性无法兼顾，你的方法他未必学到。 另外，机器是死的人数是活的，大部份服务因高负载当机的原因， 除了程式本身没处理好之外，就是死在瞬间最大流量。 瞬间最大，你要怎麽处理一瞬间的流量，妥善分配cache机制，让它可以慢慢的一笔一笔顺畅的消化掉，这才是其中学问， 淘宝为了这个瞬间最大花了不少功夫，他们有强调他们每台机器多少万人吗？ 光粗糙的看表象，永远会被牵着鼻子走。 悲哀的是，台湾十年前就有本钱问这个问题，如今这些理论大陆通通应用到了。 台湾产业十年後，还是在问这个问题。 更悲哀的是，问这个问题的公司，他自己本身也带着投机心态。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.124.28.235 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1515582075.A.E50.html