谈谈互联网后端基础设施

正文

请到「今天看啥」查看全文

• 分布式缓存：指的单独的缓存服务。几年前比较流行的是memcached，但其只是一个KV的存储，支持的数据结构太少。现在最为流行的就是Redis，能够支持丰富的数据结构，基于事件驱动的单线程非阻塞IO也能够应对高并发的场景。集群方案除了官方的redis cluster, 目前比较流行的还有豌豆荚的codis、twitter的twemproxy。

对于缓存的使用，需要注意以下几点：

• 缓存的失效机制：当给某一个key设置了有效期，那么缓存何时对此key进行删除呢？一般来说会有以下几种方式：

• 守护进程定时去扫描key，找到已经失效的key，然后删除

• 读取key的时候先去判断key是否失效，如果失效则删除并返回空。

• 缓存的淘汰机制：是当缓存内存达到上限时如何删除缓存中的key。Redis提供了以下数据淘汰策略：

• volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰

• volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰

• volatile-random：从已设置过期时间的数据集中任意选择数据淘汰

• allkeys-lru：从数据集中挑选最近最少使用的数据淘汰

• allkeys-random：从数据集中任意选择数据淘汰

• no-enviction（驱逐）：禁止驱逐数据

对于其具体的实现机制，可以参考《Redis设计与实现》一书

• 缓存的更新机制: 通常来说有四种方式：Cache aside, Read through, Write through, Write behind caching，具体的可见陈皓大神的这篇总结：缓存更新的套路。

• 缓存的服务过载保护：缓存的服务过载指的是由于缓存失效，而引起后端服务的压力骤增，进一步产生雪崩效应。这个现象和缓存更新是相关的，采取何种策略在缓存失效的时候去更新缓存直接决定了服务过载的保护机制。通常的分为客户端和服务端的应对方案。前者的方案有：基于超时的简单模式、基于超时的常规模式、基于刷新的简单模式、基于刷新的常规模式、基于刷新的续费模式。后者的方案则是很常见的流量控制和服务降级。具体的可以看美团技术团队总结的这篇文章：Cache应用中的服务过载案例研究。

数据库

数据库是后端开发中非常常见的一个服务组件。对于数据库的选型，要根据业务的特点和数据结构的特点来决定。

从存储介质上，数据库可以分为：

• 内存数据库： 数据主要存储在内存中，同时也可以采取措施对数据进行持久化到硬盘中。如Redis、H2DB的内存模式。对于这种数据库，由于内存成本昂贵，因此一定要做好存储的量化分析、容量预估，防止内存不足造成服务不可用。

• 硬盘数据库：数据存储在硬盘上的这种数据库是最为常见的。MySQL、Oracle、Postgresql、HBASE、H2DB、SqlLite等等都是硬盘数据库。此外，SSDB是基于SSD硬盘的KV数据库，支持的数据接口很丰富，是Redis的另外一个选择。

从存储数据类型、数据模式上，数据库可以分为：

• 关系型数据库：MySQL、Oracle、Postgresql都是关系型数据库的，是采用关系模型(关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织)来组织数据的数据库。

• 非关系型数据库：非关系型数据库是相对关系型数据库来讲的。以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。但是，其没有关系型数据库那种严格的数据模式，并不适合复杂的查询以及需要强事务管理的业务。非关系型数据库又可以分为：

• KV数据库：主要以(key,value)键值对存储数据的数据库。以Redis、RocksDB(levelDB)、SSDB为代表。

• 文档数据库：总体形式上也是键值对的形式，但是值里面又可以有各种数据结构：数组、键值对、字符串等等。以mongodb、couchdb为代表。

• 列数据库：也叫作稀疏大数据库，一般是用来存储海量数据的。相对于行数据库，这种数据库是以列为单位存储数据在介质上的。以Hbase、Cassendra为代表。

和数据库相关的一个很重要的就是数据库的索引。有一种说法是：“掌握了索引就等于掌握了数据库”。暂且不去评判此说法是否真的准确，但索引的确关系着数据库的读写性能。需要对数据库的索引原理做到足够的了解才能更好的使用各种数据库。通常来说，Mysql、Oracle、Mongodb这些都是使用的B树作为索引，是考虑到传统硬盘的特点后兼顾了读写性能以及范围查找需求的选择，而Hbase用得LSM则是为了提高写性能对读性能做了牺牲。

搜索引擎

搜索引擎也是后端应用中一个很关键的组件，尤其是对内容类、电商类的应用，通过关键词、关键字搜索内容、商品是一个很常见的用户场景。比较成熟的开源搜索引擎有Solr和Elasticsearch，很多中小型互联网公司搜索引擎都是基于这两个开源系统搭建的。它们都是基于Lucence来实现的，不同之处主要在于termIndex的存储、分布式架构的支持等等。

对于搜索引擎的使用，从系统熟悉、服务搭建、功能定制，需要花费较长时间。在这个过程中，需要注意以下问题：

• 搜索引擎与公司现有数据系统的集成。现有的持久化、供搜索的数据的载体是什么, 如何让搜索引擎在全量和增量建索引过程中无缝集成原来的数据载体，才能发挥搜索引擎自身的实时性, 水平扩展性(性能与容量和机器数量成正比)等优势。

• 和数据库一样，对搜索引擎的索引机制也需要做到深入的了解。

更为详细的对于搜索引擎的工程化实践可以参考有zan工程师的这篇文章：有zan搜索引擎实践(工程篇)

另外，搜索引擎还可以用在数据的多维分析上，就是GrowingIO、MixPanel中的可以任意维度查询数据报表的功能。当然，druid也许是一个更好的实现多维分析的方案，官方也有其与es的比较：http://druid.io/docs/latest/comparisons/druid-vs-elasticsearch.html。

消息队列

软件的组织结构，从开始的面向组件到SOA、SAAS是一个逐渐演变的过程。而到了今天微服务盛行的时代，你都不好意思说自己的系统只是单一的一个系统而没有解耦成一个个service。当然，小的系统的确没有拆分的必要性，但一个复杂的系统拆成一个个service做微服务架构确实是不得不做的事情。

那么问题就来了，service之间的通信如何来做呢？使用什么协议？通过什么方式调用？都是需要考虑的问题。

请到「今天看啥」查看全文