NoSQL|[挑战年薪30万]之NoSQL数据库的前世今生数据库|前端开发|jsp|网络安全

文章图片

文章图片

web系统的变迁历史web1.0

基本是一些简单的静态页面的渲染，不会涉及太多复杂的业务逻辑，功能简单单一，基本不会对服务器性能造成很大压力

缺点：

Service数量不断增加，调用关系日益复杂，构建本地环境的前端工作也不再简单。在考虑团队协作时，常常会考虑构建集中的开发服务器来解决问题。对于编译型的后端开发，这个解决方案可能会很好，但是对于前端开发就不太好了。例如：我只是想调整按钮的风格，却要本地开发，代码上传，验证生效等等几个步骤都需要做。或许习惯了也不错，但是开发服务器总是不太稳定，经常需要依靠后端开发来解决问题。表面上看，前端开发很难本地化，实际上这对研发效率的影响还很大。
【NoSQL|[挑战年薪30万]之NoSQL数据库的前世今生】JSP等代码的可维护性越来越差。 jsp非常强大，可以嵌入 Java代码。这使得前后端的职责不明确，JSP也成了一块灰色区域。通常为了赶项目进度，为了满足各种紧急需求，会在 JSP中加入大量的业务代码。积累到一定阶段，常常会产生大量的维护成本。

web2.0

伴随着 web2.0时代的到来，用户访问大大增加，同时也产生了大量的用户数据。随着智能移动设备的普及，所有互联网平台都面临着性能方面的巨大挑战。包含了web服务器的 CPU和内存压力，数据库服务器IO压力等....
有很多解决方案可以用来解决服务器的性能压力问题，最典型的就是使用 MVC的体系结构，这是一种很好的协作模式，从体系结构层面上让开发人员知道应该在哪里编写代码。要使 View层变得更加简单，您也可以选择 Velocity、 Freemaker等模板，这样就不会在模板中编写 Java代码。似乎功能变弱了，但是正是这种限制使得前后端的分工更加明确。不过，我们同样面临以下问题
前端开发严重依赖于一个开发环境。在该体系结构中，前、后端协作有两种模式：前写 demo ，让后端去套模板。包括目前仍然有大量的淘宝店铺都是这种模式。优点是 demo可以在本地开发，而且非常高效。缺点是还需要后端套版模板，有可能套版出错，套版之后还需要前端确定，来回沟通调整成本比较大。另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发，支付宝是这种模式。优点是 UI相关的代码在前端就可以全部写完，后端不用太关注，缺点是前端开发严重束缚了后端环境，环境成为影响前端开发效率的重要因素。
前后端责任依然纠缠不清。 Velocity模板还是相当强大的，其变量、逻辑、宏等特性，仍然能够通过上下文变量实现多种业务逻辑。这样一来，只要前端不够薄弱，往往会被后端要求在模板层写下大量的业务代码。此外，Controller（控制器）也是灰色地带，页面路径等功能本应是前端最关注的，但却被后端所实现。 Controller（控制器）本身也常常被 Model所缠绕，看到那些让人咬牙的代码时， Controller（控制器）层常常会出现它们。不能把所有问题都归结为程序员的素养，否则 JSP就足够了。
对于如何处理 Web服务器的负载压力，最常用的方法之一是使用 nginx来实现 Web集群的服务转发和服务拆分等等

但这也有问题，如何在后端服务器的多个 tomcat之间解决 session共享以及 session存储等问题。
对于解决 session存储的问题，还可以使用多种解决方案：

第一种方法：保存在 cookie中。没有保障，不安全！
第二种方法：存储在文件或数据库中。读取速度慢！
第三种方法： session复制。过多的会话冗余，节点浪费过大！
第四种方法：使用 NoSQL数据库缓存。比如，redis或 memcache等，完美解决

NoSQL适用场景：

高并发对数据进行读写
海量数据读写
对数据高度可扩展性
速度够快，能够快速地存取数据

NoSQL不适用场景

要求事务支持（仅限于简单的事务）
在 sql基础上建立结构化的查询存储，处理复杂的关系，需要即席查询（用户自定义查询条件的查询）。

总结：用不着sql的和用了sql也不行的情况，请考虑用NoSql
如果觉得对你有所帮助。记得收藏和关注呦！（每日更新各种大数据框架）
如需转载请注明出处（创作不易请见谅）
和巨婴程序猿一起成长。让自己变得更优秀

想了解更多精彩内容，快来关注跟着巨婴去逆袭
我最近一直在思考（大数据通俗讲解）的问题，你的看法是什么呢？关注我快说出来一起交流一下吧~