关于高性能的那点事
园子里面很多关于高性能，大并发，还有什么日pv百万的架构搭建。其实真心真心很扯淡。对于大部分应用来说，想要高性能，主要是要做到尽可能的减少网络请求(含db、redis、mongo、mq等)。几乎所有的应用，性能瓶颈永远是在带宽那里，硬件方面这里就不提了，说说我们能做的事。
找了半天没有找到那张图，关于各个组件到cpu的时间周期，我用文字描述一下，L1>L2>memory>disk>internet。
有人说redis性能高，做大并发，大数据访问必须要用，有人说mongo性能高，什么zeromq等等一系列的，其实都是渣。
先说网络请求，关于tcp/ip:
大家都知道ip是逐跳协议，也就是说我只能从一个路由器，到下一个路由器，再到下一个路由器，如果你的电脑到服务器，中途要经过很多个路由器，那时间周期就会长很多很多恨多。为什么要做cdn、p2p等也是这个考虑，缩短网络的路径（降低带宽承载也是一方面）。
再说redis、mongo:
举个简单的例子，我有一个游戏服务器，在线人数约4000，里面是一个状态机在跑，需要不断的去检测各种状态，经验，星座，任务开放，技能开放等等。一个玩家大约10个状态的判定，4000个玩家必须在200ms之内检测完毕，不然延迟会很严重，那1s就是大约执行5次，如果每一次数据都去redis去取，大约是5*10*4000 = 200k次，别说redis，怎样的牛B的服务器都顶不住，这还是只有1个服。
那么问题来了：怎么解决呢？
把数据放在内存里面，直接从内存取，然后foreach。大部分的应用优化到这里，基本上应付所谓的日pv百万，就不是什么问题了。
到了这一步，那么问题来了，对于内部应用，比如分布式文件存储，数据分析，任务调度。肿么破？
对于大数据，其实一直是一个伪命题，数据量太大属于硬伤。所有的做大数据处理的，都是把数据分成小数据，然后分块来处理，最后再合并。其实从mysql,oracle,mssql等一系列rmdb的分区，分库上的处理就可以看出来。想要提高性能，必须要做到，每个模块处理的数据量，都是细分到了一定粒度的。这个时候index, group, hash等的重要性，在这里就体现出来了。
举个简单的例子：我有一个业务系统，每天的日志大约是10个G，一个月就大约是300g，一季度大约1T，我需要看每小时/每天/每周/每月/每季度的各种报表，每次都去数T里面去找，肯定是不可能的。
那么问题来了：怎么解决呢？
按业务分析每分钟的数据，10g/24/60大约7M，然后生成一个分析后的结果文件，大约几k，1小时就是60个文件，需要查看每小时的数据，则将60个文件的结果合并。具体粒度可按具体业务定制，这个是比较简单的分组的例子。
那我需要查看某一个用户，最近10天来的所有操作/订单，那原分组方式，已经无法满足，这个时候怎么办呢？
在插入用户数据的时候，可以按照一定规则，比如用户编号的后两位取摸，去存储在某一个文件里面，10g的数据，则可以相对平均的分配到100个文件里面去，需要查看某用户时，则可以针对用户编号取摸，直接定位到那个文件，然后再去里面查询数据。这个是比较简单的gourp+index。这一块想明白以后，你就可以在这个基础上面，写个定制化的简单的fs了(当然了，实际情况需要考虑的会更多，包括内存换入换出等，不在本文列举)。
经常听到有人说，多线程的程序还不如单线程的程序性能高。那如何编写一个能合理利用cpu资源的多线程程序？
大家都知道，线程切换是需要额外的开销，所以在编写多线程程序的时候，就需要尽可能的避免共享式资源，这样就可以在保证数据一致性的同时，而又避开线程等待的时间。
举个简单的例子：
我有个大的字典(Dictionary/Map)存放用户的会话数据，每个线程，去这个字典里面去读/写数据的时候，都需要去上锁，才能保证数据的一致性，如果两个(更多)线程同时去读/写数据，其他的线程就需要去等待当前线程释放资源，线程越多，则等待的几率越大，性能则越差，多线程处理变成了单线程处理，且等待完了以后，能否再切换回来这个线程继续执行，又是另外一个开销，这一部分属于系统拖托管，属于不可控的。
那么问题来了：怎么解决呢？
根据硬件和实际测试数据，合理分配线程资源，比如，我初始化了8个线程，每个用户的请求，对于线程总数取摸，保证每个用户的请求，入同一个线程处理，则可以在每个线程内部，存放这些用户数据，每个线程在自己内部进行存取，避开了lock，也避开了线程等待/切换带来的资源开销。不取模，随机分配线程，然后用一个hash表来存放，也可。让每个线程，专注于做自己的事情，任务调度作业，也大是基于这个处理。把线程处理机制，放大到虚拟机/物理机之间的消息分发，也大是如此。
还有很多很多，不一一列举，具体业务，视具体情况而定。
总体来说，避开网络开销，避开海量数据，避开资源争夺 是所有高性能的几个基本要素。
