大型网站我认为指的是高并发，海量数据，业务复杂的网站，搭建这类网站往往需要多种角度技术优化，本文所述的有些技术我并没有实战经验，在这里只是记录一下，以备后续学习
一、数据库相关问题
大型网站一般最容易产生的性能瓶颈就是数据库，因为关系型数据库所能承受的并发链接数是很有限的，可以从以下几点做出优化
1.数据库查询做好足够优化，大多数的网站往往读的次数要远远高于写的次数，尽快将数据取出来，关闭链接，释放资源当然是最简单，也是首要做的。
- 查询的数据库表字段做好适当的索引；
- 查询的时候只查需要的字段，不需要的字段不要写；
- 尽量避免索引失效的查询，例如模糊匹配，In查询；
- 尽量避免事务性提交，事务会造成锁表，而且处理的不好还容易造成死锁，可以将这种事务转交给程序处理，应用分布式锁可以有效减轻数据库负担，后面还会有简单介绍；
- 不要用触发器，一般情况
- 如模糊查询次数较为频繁，数据量较大，建议使用全文搜索引擎，如Lucene,这个是java和.net平台用的较多的，网上资料也非常丰富，http://www.cnblogs.com/MeteorSeed/archive/2012/12/24/2703716.html，其他的就不多说了，这些是最基本的知识
2.切库，切库能有效的避免高并发所带来的压力，也是较为简单的一种方式，切库又分为两种垂直切库和水平切库。
- 以业务角度，将数据库拆分成两个数据库，分别放在两台服务器上，这种方式叫做垂直切库；
- 当一张表数据量太庞大，将一张表拆分成多张表，这叫水平分库；
分库首先会带来两个问题
- 那就是Join查询，当两张表分别放在两个数据库时Join查询的效率时非常低的，要避免这种情况产生，可以将之分为多次查询
- 当涉及到增删改的时候，事务性提交时，如果涉及到多张表存放在不同数据库，是无法实现的
要尽量避免以上情况就要注意分库的时候拆表的粒度问题，把关联性高的表放在同一个数据库
水平分库更为复杂不光存在以上问题，而且还增加了其它需要解决的问题
- 上述的两个问题在水平切库时会大大增加了问题的难度，因为拆分的维度变得更大的；
- 水平分库时还需注意主键的设计将会是一个难题；
- 还有就是我们要按照什么逻辑将数据存放到那些被拆分的不同的表里；
- 当表变得越来越多时，不管是开发和维护的工作量还是服务器的管理上都会增加越来越大的压力
1）.水平分表时，我们可以根据数据的热度进行拆分，例如订单表我们可以将一个月之类的订单放在一张表里，其余的放在另一张表，这样就能大大提高我们的查询效率
2）.水平拆表时我们需要注意被拆分的表主键不可重复，因为这本该是同一张表的，http://www.cnblogs.com/heyuquan/p/3261250.html
3）.有时候我们需要从水平拆分的不同表中一起查询数据，这个难度实现起来就有点大了，我们应该尽量避免，实际上大多数情况下我们都无需将所有数据返回，我们应该从业务角度去避免这种情况的产生，很多时候我们都是没有完美的解决方案的，有得必有舍
就像第一点所说的拆分订单之后，我们可以提供两个标签页一个提供查询一个人之内的订单，另一个提供查询历史订单
能在业务角度解决的，尽量避免使用技术去解决，因为这往往会增加风险，所以在这之前应做好充分的评估
3.主从复制，读写分离
读写分离如果数据库的压力过大这时我们可以将数据库进行读写分离，写入单独用一个数据库，做为主库，读取用多个数据库，做为从数据库，做负载均衡，主数据库向从数据库同步数据，但是这会产生一定的延迟性，因为你无法保证读出的数据是不是最新的，所以这需要去评估一下这么做是否合适，http://www.cnblogs.com/netfocus/p/4055346.html 如果既要保证实时性，又要用读写分离，我们可以使用一个中间层，写入数据库的同时，将数据写入中间层，直到确认数据已经同步完成，就将数据从中间层删除，读取时这部分数据先从中间层读取,然后从数据库读取，重复的数据以中间层为准，因为中间层总是最新的，但是有一个问题是我们无法得知数据是否确定已经同步，这个就需要我们去创建一个监控程序用来将从数据库的数据与中间层对比，确认同步完成，这是我的个人想法，还没有实践过
4.队列和分组提交
- 当主数据库写入同一时间并发量太大很容易造成数据库崩溃，这种情况可以将请求先排入队列，同一时间允许一定数量的任务同时执行，但是这种情况可能会造成延迟响应，但是延迟响应总比直接崩溃的好，关于队列后续还会有简单介绍；
- Group commit 大量写入请求我们可以将请求分组多次请求做为一次提交，例如多次请求减少某个商品的数量时我们可以将请求做为一次提交同时减去相应的数量，还可以将多个请求放入同一个数据库连接中，因为数据库的链接打开关闭也是非常消耗资源的，这里要把控好相应的尺度
5.缓存
当一组数据经常读取而更新次数不多，允许一定延迟时，我们可以将数据放入缓存中，缓存能够大大的降低数据库的负担，内存的读取速度是磁盘的数万倍，下面还会进行介绍
6.Nosql
现在Nosql的解决方案已经是数不胜数了，例如国内使用较多的Mongodb，http://www.cnblogs.com/huangxincheng/archive/2012/02/18/2356595.html，关系型数据库与Nosql数据库的搭配能有效的降低服务的延迟性
二、其它相关问题
1.分布式应用所面临的问题和解决方式
大型网站为了能够承受住大的访问并发量，web服务器肯定也会进行负载均衡，实现方式有很多种，例如Nginx反向代理，dns负载均衡，ip负载均衡，http://www.open-open.com/lib/view/open1416924842581.html
http://blog.sina.com.cn/s/blog_493a84550102vjlq.html http://www.cnblogs.com/edisonchou/p/4126742.html http://www.cnblogs.com/edisonchou/p/4281978.html
分布式系统至少会面临4个问题需要解决
1).如果网站中运用了线程锁，在分布式网站部署在不同地方，如果我们的业务逻辑是同一时间只能有一个线程处理，那么这时我们就需要使用分布式锁了，前面所提到的当大量的行锁、表锁、事务充斥着数据库的时候，数据库会造成很多压力，这里给大家介绍的是减轻数据库锁负担的一种方案,使用zookeeper分布式锁服务，http://www.cnblogs.com/shanyou/archive/2012/09/22/2697818.html，http://www.cnblogs.com/shanyou/p/3221990.html
2）网站一般都会有些配置信息，当网站部署于不同地方时，要维护就变得相对麻烦一下，zookeeper也提供了响应的配置管理，
3）网站一般都会有上传图片，海量的图片管理也是一个需要解决的问题，分布式文件系统有很多解决方案，这里介绍一种方式 FastDFS 链接地址 http://www.cnblogs.com/lori/p/3142598.html
4）分布式缓存，分布式缓存有很多解决方案。
- Memcached http://www.cnblogs.com/HCCZX/archive/2012/12/23/2829645.html
- Redis http://www.cnblogs.com/yangecnu/p/Introduct-Redis-in-DotNET-Part2.html
- SSDB http://www.cnblogs.com/shanyou/p/3496163.html
2.分布式消息队列
当网站中有大量的任务堆积需要等待处理时，例如短信发送，邮件发送，数据库的操作延时任务，我们一般都是采用队列来处理，下面介绍几种队列组件
ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP，下载地址 http://activemq.apache.org/ C# client http://activemq.apache.org/nms/
Beanstalk 是一个简单、快速的消息队列。Beanstalkd之于RabbitMQ，就好比Nginx之于Apache，Varnish之于Squid。后面在项目中使用Beanstalkd的过程中，更发现其简单、轻量级、高性能、易使用等特点，以及优先级、多队列、持久化、分布式容错、超时控制等特性。Beanstalkd 包含多种编程语言的客户端开发包 C# client https://github.com/kr/beanstalkd/wiki/client-libraries
kafka是一种高吞吐量的分布式发布订阅消息系统 http://kafka.apache.org/documentation.html C# client https://github.com/Jroland/kafka-net