首先声明一下，本人并没有遇上多大的高并发经历。只是有过一些调优经历而已。
外头现在什么都说一开始有几十万用户什么的，也不管是不是真的有这么多的用户，下面只从技术出发，不扯运营问题。
IO短板
首先我们猜测一下网站在高并发通常是那一部分出问题，就像桶子装水，短板决定着能装的水量。个人看法最容易出问题的地方是磁盘的IO，磁盘访问速度还是相对较慢的，每秒钟可以读写的数据有限。如果你每次访问网站都要读取磁盘的话，如果访问人数多起来，那么越来越多的用户就要等待其他用户在磁盘读取完所需的数据，等待的人越来越多，后面的用户由于等待时间过长就会出现504网关超时（大哭了）。
既然说磁盘是最有可能出现问题的地方，我们就要针对这个做一些特殊处理。网站读写磁盘严重的地方有哪些呢？一般来说是数据库读写，上传文件保存，静态资源文件的读取。那么我们一一做一些优化，数据库优化其实是最重要的，很多网站性能问题其实出现在数据库身上。优化数据库第一个就是减少数据库读写啦，所以尽量不要在代码中来一个循环读取数据库（这真的是一个悲剧），能一条sql解决的就用一条（当然这不是绝对的）。第二个就是不读数据库好不好（其实就是代码缓存读取结果，数据一致性是一个问题）。第三个就是避免并发写入数据库，写入是避免不了的啦，我们做的就是错峰出行，这样子就能保证在每一个时间点空出资源做更多的事情。那文件保存，静态资源读取又该怎么办呢？你可以简单粗暴的土豪式作风独立一台静态资源服务器，独立文件服务器之后哪怕文件服务器慢，也不会影响主线业务正常访问，并且文件服务器慢了你可以上集群呢。没这么多资金怎么办，那么就要主动一些，告诉浏览器，这些文件访问一次之后你一段时间都不要过来问我哈（这事情要自己主动，如果浏览器不理你偏要访问我也没辙了）。一般来说我们的好朋友apache和nginx可以帮我们告诉浏览器要缓存一下静态资源（但是这事情我们要主动～配置一下，具体自己查阅文档了）。
带宽短板
磁盘问题我们优化完之后，并不是就是一帆风顺的。技术路是曲折的，另一个短板最有可能是什么呢？个人经验认为是带宽，第一种解决方案，你不缺钱直接买带宽就好。作为弱小的开发者我选择第二种解决方案，减少请求自己的服务器 ，我们可以把一些第三方库放在公共服务提供商，例如jquery，bootstrap这些，我们用一些厂商提供的cdn服务就好，用户就不用访问我们自己的服务器咯。同时减少每次访问的资源大小，减少的办法主要是压缩，我们的图片，自己封装的js都先压缩了再给用户，虽然压缩节省可能就几十K，然而小数怕长计（我相信大家都懂的）。这两步之后我们还能做什么呢？一个非常重要的事情，其实我们很多资源是长时间不变的，so还是要主动一些（主动告诉浏览器第二次访问请在自己的缓存读取，不要问我大服务器哥。。。）。
cpu短板
然后这两个短板告一段落咯，我们聊一下下一个短板（也不短咯）-------CPU，cpu达到100%的几率不太常见（这也是我经历的不多，唯一一次看到是mysql吃光了cpu）。cpu占有率高往往是涉及到大量运算的场景，解决方案是什么呢。我们使用万能解决方案，缓存结果。就像你计算1到100万的阶乘，计算一次就好了，第二次不要计算直接用第一次的结果就好了，这样子就不用浪费CPU了嘛，如果mysql吃光CPU的话，往往也是mysql在进行复杂的运算（我们体谅一下他，缓存一些结果，别让她受这么多苦头），并且看到mysql占用cpu的话，我们还要针对性优化它（具体优化以后再专门写文章闲扯一下）。
内存短板
然后我们扯一下内存，我们知道内存读写速度非常快，我们之前万能解决方案-----缓存依托的主要也是内存。然而我们把大量数据都扔到内存里面之后，内容慢慢的慢慢的就不够用了。这个时候我们就要删掉一些数据（一般删掉以后不再使用的数据啦，然而迫于无奈的时候我们只能删除一些使用频率低的数据），由于我是懒人，所以我希望有程序帮我自动删除数据保证内存有空余资源，这个时候我找到了一个叫redis一个叫memcached的家伙，他们都能帮我们处理好缓存的数据，根据算法删除一些数据。（两者区别，下次再扯一下）
个人看法
个人观点，高并发并不可怕。都说兵来将挡水来土掩，高并发也一样。找到短板，补好它，服务器哥就能继续愉快的玩耍咯。缓存的作用是非常巨大的，我们要合理利用好，但是它也不是万能膏药，如果这么简单，还要架构师干什么呢（大笑）。
