对于现阶段到我来说，很难有大型到项目去做，都是来了一个需求，然后开始将这个项目实现，远远达不到那种一天几十万到访问量，需要并发特别高到项目。这个也许其他程序员也有这样到体会。毕竟能够说出来牛叉到项目没有多少，我们都是在堆需求，然后让项目在一定情况下稳定。
没有这种大项目让自己练手，就不学习了吗，这种观点是错误到，即使现在有一个大型项目，要求特别高，我们没有试错过，一样弄不好，那么就需要在平时将自己搭建到项目到要求提高。
刚开始一个项目也是从单机开始，不过现在搭建到项目使用到了dubbo,将服务模块化，分为了，数据访问服务，对外提供接口服务，这种方式已经将项目的结构有了一定到可扩展性，同时比以前到单机服务要复杂一些。单机版到项目上线后，然后和测试人员一起配合做压测。压测的情况反应过来后，要思考如何能够提升服务器到性能。
首先一个网站到访问量即pv,大概估值是多少，然后去计算并发量，这里有一个计算公式，每天有10W的到访问量，而这10W的访问量一般都是在白天到时候访问，100000/(8 * 60 * 60)=3.47。即每秒都4次到并发量，一般到服务器也能够支撑的了这样到访问量，但是实际情况不是这样的，根据二八原则，在20%到时间内有80%到访问量，那么公式需要重新计算(100000 * 0.8) / (8 * 60 * 60 * 0.2) = 13.89,即每秒有14次的并发量。这个是10W的并发量，如果继续增大，那么服务器能够出现问题呢？让测试到同事压测一下，提升访问量后，服务器出现什么问题，然后在每次压测到时候，观察后台到日志，观察那方面查询速度慢，哪些地方出现问题。
在并发到情况下，资源容易出现脏数据，不正确的数据，特别是关于钱的计算，这里举一个例子，对金额的修改的时候，一般是查询出来，然后对金额进行计算，最后插入到数据库。在单个线程访问的时候是没有问题的，但是并发的情况下，当对金额进行修改的时候，查询出来了，准备进行修改的动作，另一个线程进来，也需要修改金额，查询出来的金额是没有修改过的金额，在这种情况下，金额就减少了。如何避免，这在数据层面上做操作，如update tb_amount set money = money-10 where id =1,这种方式，传入金额后，在数据层面上，会对单行进行加锁，这样就能够保证了数据在并发情况了也正确。
根据压测的报告和观察到的结果，查看哪些数据访问频率特别高，这些数据是否可以放入缓存。放入缓存后，如果对数据修改时，采用哪种方式来保证数据一致性。项目中加入了redis作为缓存，将查询高频的数据放入缓存中，那么项目中的层级结构就发生了变化。需要心目中描绘出这种关系图。但是加入了缓存，需要思考，如果数据被修改后怎样保证一致性，这个时候网上的一致观点是，修改数据库中的数据，然后删除或者过期缓存中的数据。在查询的时候，查询不到数据后在访问数据库，然后将数据缓存到redis中，使用到了Cache-Aside pattern模式，特点：
- 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存失效。
更深入思考如果再高并发的情况下，某一个时刻大量的数据都失效后，请求都访问数据库，导致数据库崩掉，那这个时候该如何解决，网络上就有关于redis缓存穿透、缓存雪崩和缓存击穿这些问题的解决方案。
解决了redis的相关问题，数据库上访问是否也可以进行优化，提升单台数据库的访问效率，而不至于一下子就来扩展数据库。而关于mysql的优化，一般操作为，优化mysql语句，建立索引，增加mysql的访问连接数，后续可能深入到mysql底层，进行调优。
以上都是数据库层面的优化，并且一般情况下，一个程序的压力大多在数据库层面，至于之后的提高系统稳定性，提高系统的访问连接数，可以服务横向扩展。
数据库提供层扩展，dubbo可以一下子就能够完成，而访问层的扩展，可以使用nginx这种转发代理的方式做。
这样假想程序的日访问量达到10W的访问量，系统能够支撑的了，等真正的访问量达到了，那么后续扩展日访问量100W的量，在继续思考如何扩展。如果项目就这样戛然而止了，那自己也学习到了10W访问量的架构设计，系统优化的经验。