简历相关

1、freemarker

     thymleaf :

         优点：springboot推荐使用thymleaf，thymleaf最大好处是模板文件可以被直接打开，方便前后端分离。

         缺点：根据测评结果，速度比较慢。官方也不谈效率。

   jsp：

        太老，太土，太重，不考虑。

   freemarker:

       优点：速度居中，没有上一代追求速度的velociy快，也没有编译后的jsp快，但是还是一个数量级上的速度，比thymleaf要快上一个数量级。然后提供的功能比较全面，函数、directive等支持都比较齐全。shop++也使用了freemark，我们看情况可以参考使用，其次可以将其中的一些模板修改使用。

      缺点：跟thymleaf来比，必须要在程序里渲染才能看到页面。跟jsp比，速度略逊，而且不是官方的，插件等支持不如jsp丰富。

 

选择原因：速度相对比较优秀，功能齐全，文档完善，从shop++上有一些迁移也会比较方便。

freemarker文档：http://freemarker.org/docs/pgui.html

 

 

2、搜索引擎solor：

       es：

           优点：支持广泛，使用度高，最大好处是支持分布式，拥有自己的查询语法。

           缺点：没有很特别缺点，如果非要说缺点就是把lucene改动比较大，学习成本相对比较高。

      lucene:

          他们都是基于lucene制作的，但是lucene太原始了，只是个搜索数据库，缺少管理，开发比较底层比较费时，有功能更改还需要自己封装很多。

      solor：

          优点：拥有自己的管理页面、工具以及一些企业化方式封装。比较方便使用。学习成本应该可控。

          缺点：不如es扩展性来的好，但是我们数据量并不会特别大。其他暂时不清楚。

 

选择原因：shop++搜索基于solor实现，如果从头实现我会选择es，因为我们已经有es使用和管理的经验，并且有自己的es集群，使用solor我们需要搭建自己的solor服务器，成本比较高，但是从开发成本上来讲，还是会偏向于solor，可能稍微改造参照我们就可以发展出自己的搜索服务，我们并不会有海量数据需要水平扩展。性能上来讲我觉得应该不是问题，solor也是企业级的应用框架，也有自己的管理页面。

 

注：目前SHOP++4.0已经转上Hibernate search 4.0，是hibernate对lucence的封装，目前的了解只是使用起来非常简单方便，需要具体了解，再决定我们搜索到底用哪个。还没拿到shop++4.0代码。

 

3、zookeeper:

      我们已经有使用经验，从目前测试环境反映来看比较稳定了，马上就会在通用产品正式环境使用。详细请参考howto: 使用zookeeper进行服务注册、服务发现、服务管理

 

4、缓存和高效键值对存储，redis

      memcache：

        优点：非常高效，使用非常简单。运维成本要比redis低。

        缺点：数据结果比较简单，对数据内容的扩展性比较差，必须要进行序列化和反序列化。而且没有库的概念，所有的数据必须手工去区分。适合数据结构非常简单的但数据量非常大业务场景。

      mongo：

        就是个nosql数据库，在键值对的处理速度上是不及redis和memcache的（在速度和吞吐量上说，其实是完全可以满足我们需求的，我们目前可以看见的数据量和速度上要求都不高）。

      redis：

         优点：使用人非常多，键值对存储，并且可以按照合适的策略变成高速的数据库，支持一定的事务，并且有五种数据结构，可以满足普通键值对，set，hash，list，sorted set，并且有比较丰富的方法支持increase排序等操作。

         缺点：我们目前没有使用实践，数据结构上的选择一开始也会比较困难。

       ehcache:

         优点：做本机缓存使用，可以很方便的文件和内存转换，并且可以很好的跟springboot进行融合。使用比较简单，维护成本低。

         缺点：不能做分布式缓存。

 

选择原因：

   以后如果业务上有任何变化，可以很方便的支持，并且很好扩展。其次使用redis进行一个实例上分库做不同类型的缓存和使用也很方便，在我们的业务场景下，我们选择redis对以后业务上发展绝对是有好处的。学习成本上的劣势完全不是问题，而且redis我们团队也必须是要掌握的一门很普通的技术。网上的学习资料和使用实践也是数不清的。

   mongo是纯的数据库，不支持键的定时过期，刷新缓存时间这种特性，必须手动让其过期，增加逻辑复杂度，增加数据管理难度。缓存数据定时过期策略交给持久化设备来管理在逻辑上是最好理解的。

转载于:https://www.cnblogs.com/longling2344/p/6650452.html