app后台技术

首先应用程序框架，随你自己业务需求而定，可以选择SSH或者SSM，或者看自己业务量大小。

其次，并发量不是应用程序可以控制的，而是服务器架构。

你要先估算自己的应用的最高并发量，还有访问频率，总用户量等等。

一般来说，基本的服务器架构应该是Nginx（可考虑双击或集群）+ Tomcat（集群） + Redis/Memcached（集群） + 缓冲队列 + MySQL（读写分离或集群）

Nginx：高性能的反向代理和负载均衡，比Apache好一些，主要作用是做动静分离（例如广告等静态图片或者页面），还有是负载均衡、分流的作用，具体怎么均衡，查阅相关资料，有好几种方式，有基于IP的hash，基于URL的hash等等

Tomcat：Java的Web应用程序都是部署在Tomcat上(默认配置500连接)，至于Web程序开发可以SSH或者SSM框架，自己选择。Tomcat最好是集群，而且每个Web应用模块双部署，即使一个服务器上的Web应用不能访问时，要立马切换到正常的那台（可以Nginx实现）。然后这部分应该考虑的问题，就是session会话共享，要把session在各台服务器之间同步或者共享到同一地方。个人倾向于后者，因为后者可以用缓存服务器来代替，来存储session信息。即下面讲的Redis/Memcached。

Redis/Memcahed：因为Web应用80%的数据都是读，20%为写。即2、8定律，所以缓存是必须的。如果没有缓存，数据库的承受压力太大，会导致高峰时，拒绝连接。因为缓存用的是内存，所以读取操作数据，会更快。按照Redis的官方测试结果，读性能可达将近10W(具体忘记了)。而Redis/Memcached都是缓存服务器，哪一个较好呢。前几年时，是memcached比较流行，而最近几年Redis火了之后，因为它的高性能，可持久化，支持多种数据结构等优势，为更多人所采用。

MySQL：这里也可以选用其它更好的数据库，如商业级的oracle。数据库可支持的连接数并不是很多，Mysql默认配置为100条连接，其中还有1条保留给root用的。所以最多同时99条连接，当然配置是可以改的，但不会太高。所以数据库要根据业务需求，做读写分离，或者集群，或者两者都有。但是备份一定要有的，热备份和冷备份建议都要有。前面说了，采用Redis/Memcached缓存可以有效的降低数据库的压力，如果这时还不能满足，那可以选择加一个缓冲队列，把操作写入队列中，再从队列中慢慢读取，慢慢插入数据库。常见队列为Redis，ActivaMq，rabbitmq等等

最后，上面都是理论知识，如果真要实践起来，每一项都要花费一段时间去研究，而且还要根据自己的需求做调整，优化之类的。最后说明一点，能简单就别复杂化，越复杂化考虑的东西就越多。

例如数据库我一台就够用了，就不要做读写分离，因为读写分离会导致数据不一致，不及时同步之类的问题。所以，能用简单的方案，就用简单方案。

框架设计

业务层次模型划分