基本上就是一些简单的静态页面的渲染,不会涉及到太多的复杂业务逻辑,功能简单单一,基本上服务器性能不会有太大压力前端
缺点:一、Service 愈来愈多,调用关系变复杂,前端搭建本地环境再也不是一件简单的事。考虑团队协做,每每会考虑搭建集中式的开发服务器来解决。这种解决方案对编译型的后端开发来讲也许还好,但对前端开发来讲并不友好。天哪,我只是想调整下按钮样式,却要本地开发、代码上传、验证生效等好几个步骤。也许习惯了也还好,但开发服务器老是不那么稳定,出问题时每每须要依赖后端开发搞定。看似仅仅是前端开发难以本地化,但这对研发效率的影响其实蛮大。nginx
二、JSP 等代码的可维护性愈来愈差。JSP 很是强大,能够内嵌 Java 代码。这种强大使得先后端的职责不清晰,JSP 变成了一个灰色地带。常常为了赶项目,为了各类紧急需求,会在 JSP 里揉杂大量业务代码。积攒到必定阶段时,每每会带来大量维护成本。程序员
随着Web2.0的时代的到来,用户访问量大幅度提高,同时产生了大量的用户数据。加上后来的智能移动设备的普及,全部的互联网平台都面临了巨大的性能挑战。包括web服务器CPU及内存压力。数据库服务器IO压力等web
为了解决服务器的性能压力问题,出现了各类各样的解决方案,最典型的就是使用MVC的架构,MVC 是个很是好的协做模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还能够选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。看起来是功能变弱了,但正是这种限制使得先后端分工更清晰。可是一样也会面临如下问题redis
一、前端开发重度依赖开发环境。这种架构下,先后端协做有两种模式:一种是前端写 demo,写好后,让后端去套模板。淘宝早期包括如今依旧有大量业务线是这种模式。好处很明显,demo 能够本地开发,很高效。不足是还须要后端套模板,有可能套错,套完后还须要前端肯定,来回沟通调整的成本比较大。另外一种协做模式是前端负责浏览器端的全部开发和服务器端的 View 层模板开发,支付宝是这种模式。好处是 UI 相关的代码都是前端去写就好,后端不用太关注,不足就是前端开发重度绑定后端环境,环境成为影响前端开发效率的重要因素。sql
二、先后端职责依旧纠缠不清。Velocity 模板仍是蛮强大的,变量、逻辑、宏等特性,依旧能够经过拿到的上下文变量来实现各类业务逻辑。这样,只要前端弱势一点,每每就会被后端要求在模板层写出很多业务代码。还有一个很大的灰色地带是 Controller,页面路由等功能本应该是前端最关注的,但倒是由后端来实现。Controller 自己与 Model 每每也会纠缠不清,看了让人咬牙的代码常常会出如今 Controller 层。这些问题不能全归结于程序员的素养,不然 JSP 就够了。数据库
关于如何解决Web服务器的负载压力,其中最经常使用的一种方式就是使用nginx实现web集群的服务转发以及服务拆分等等json
可是这样也会存在问题,后端服务器的多个tomcat之间如何解决session共享的问题,以及session存放的问题等等后端
为了解决session存放的问题,也有多种解决方案浏览器
方案一:存放在cookie里面。不安全,否认
方案二:存放在文件或者数据库当中。速度慢
方案三:session复制。大量session冗余,节点浪费大
方案四:使用NoSQL缓存数据库。例如redis或者memcache等,完美解决
NoSQL适用场景
NoSQL不适用场景
总结:用不着sql的和用了sql也不行的状况,请考虑用NoSql
redis官网地址:
中文网站
Redis是当前比较热门的NOSQL系统之一,它是一个开源的使用ANSI c语言编写的key-value存储系统(区别于MySQL的二维表格的形式存储。)。和Memcache相似,但很大程度补偿了Memcache的不足。和Memcache同样,Redis数据都是缓存在计算机内存中,不一样的是,Memcache只能将数据缓存到内存中,没法自动按期写入硬盘,这就表示,一断电或重启,内存清空,数据丢失。因此Memcache的应用场景适用于缓存无需持久化的数据。而Redis不一样的是它会周期性的把更新的数据写入磁盘或者把修改操做写入追加的记录文件,实现数据的持久化
1.取最新N个数据的操做
好比典型的取你网站的最新文章,经过下面方式,咱们能够将最新的5000条评论的ID放在Redis的List集合中,并将超出集合部分从数据库获取
FUNCTION get_latest_comments(start,num_items):
id_list = redis.lrange("latest.comments",start,start+num_items-1)
IF id_list.length < num_items
id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END
若是你还有不一样的筛选维度,好比某个分类的最新N条,那么你能够再建一个按此分类的List,只存ID的话,Redis是很是高效的。
2.排行榜应用,取TOP N操做
这个需求与上面需求的不一样之处在于,前面操做以时间为权重,这个是以某个条件为权重,好比按顶的次数排序,这时候就须要咱们的sorted set出马了,将你要排序的值设置成sorted set的score,将具体的数据设置成相应的value,每次只须要执行一条ZADD命令便可。
3.须要精准设定过时时间的应用
好比你能够把上面说到的sorted set的score值设置成过时时间的时间戳,那么就能够简单地经过过时时间排序,定时清除过时数据了,不只是清除Redis中的过时数据,你彻底能够把Redis里这个过时时间当成是对数据库中数据的索引,用Redis来找出哪些数据须要过时删除,而后再精准地从数据库中删除相应的记录。
4.计数器应用
Redis的命令都是原子性的,你能够轻松地利用INCR,DECR命令来构建计数器系统。
5.Uniq操做,获取某段时间全部数据排重值
这个使用Redis的set数据结构最合适了,只须要不断地将数据往set中扔就好了,set意为集合,因此会自动排重。
6.实时系统,反垃圾系统
经过上面说到的set功能,你能够知道一个终端用户是否进行了某个操做,能够找到其操做的集合并进行分析统计对比等。没有作不到,只有想不到。
7.Pub/Sub构建实时消息系统
Redis的Pub/Sub系统能够构建实时的消息系统,好比不少用Pub/Sub构建的实时聊天系统的例子。
8.构建队列系统
使用list能够构建队列系统,使用sorted set甚至能够构建有优先级的队列系统。
9.缓存
将数据直接存放到内存中,性能优于Memcached,数据结构更多样化。
高效性:Redis读取的速度是110000次/s,写的速度是81000次/s
原子性:Redis的全部操做都是原子性的,同时Redis还支持对几个操做全并后的原子性执行。
支持多种数据结构:string(字符串);list(列表);hash(哈希),set(集合);zset(有序集合)
稳定性:持久化,主从复制(集群)
其余特性:支持过时时间,支持事务,消息订阅。