redis/nginx/dubbo/solr 中间件小总结

最新推荐文章于 2024-08-22 19:00:00 发布

返克

最新推荐文章于 2024-08-22 19:00:00 发布

阅读量982

点赞数 1

文章标签： redis nginx dubbo solr

本文链接：https://blog.csdn.net/qq_36648082/article/details/89891297

版权

Redis

Redis 是开源免费的，遵守BSD协议，是一个高性能的key-value非关系型数据库。单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。redis采用多路复用机制：即多个网络socket复用一个io线程，实际是单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流. 。可以减轻数据库压力，查询内存比查询数据库效率高。

三种可执行文件：

redis-server：Redis服务器程序

redis-cli：Redis客户端程序，它是一个命令行操作工具。也可以使用telnet根据其纯文本协议操作。

redis-benchmark：Redis性能测试工具，测试Redis在你的系统及配置下的读写性能。

redis数据结构：存储字符串、存储List类型、存储Set、存储Hash、存储sortedSet、kry通用操作

redis数据类型及使用场景

(一)String：最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

(二)hash：存放的是结构化的对象，比较方便的就是操作其中的某个字段。单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

(三)list：使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。

(四)set：因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

(五)sorted set：sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。另外，参照另一篇《分布式之延时任务方案解析》，该文指出了sorted set可以用来做延时任务。最后一个应用就是可以做范围查找。

redis持久化

RDB持久化：是在某个时间点将数据写入一个临时文件dump.rdb，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复，采用二进制文件形式进行存储。优：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能。缺：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

执行数据写入到临时文件的时间点是可以通过配置来自己确定的，通过配置redis 在 n 秒内如果超过 m 个key 被修改这执行一次 RDB 操作。这个操作就类似于在这个时间点来保存一次 Redis 的所有数据，一次快照数据。所有这个持久化方法也通常叫做 snapshots。

AOF持久化：Append-only file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在 append 操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串，非常容易阅读和解析。

优：可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果 redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；aof文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）。

缺：AOF 文件比 RDB 文件大，且恢复速度慢。

如果 server 中持续的大量变更操作，将会导致 AOF 文件非常的庞大，意味着 server 失效后，数据恢复的过程将会很长；事实上，一条数据经过多次变更，将会产生多条 AOF 记录，其实只要保存当前的状态，历史的操作记录是可以抛弃的；

AOF与RDB区别

1) AOF 更加安全，可以将数据更加及时的同步到文件中，但是 AOF 需要较多的磁盘 IO 开支，AOF 文件尺寸较大，文件内容恢复数度相对较慢。

2) rdb，安全性较差，它是“正常时期”数据备份以及 master-slave 数据同步的最佳手段，文件尺寸较小，恢复数度较快。

可以通过配置文件来指定它们中的一种，或者同时使用它们(不建议同时使用)，或者全部禁用，在架构良好的环境中，master 通常使用AOF，slave 使用rdb，主要原因是 master 需要首先确保数据完整性，它作为数据备份的第一选择；slave 提供只读服务(目前 slave 只能提供读取服务)，它的主要目的就是快速响应客户端 read 请求；但是如果你的 redis 运行在网络稳定性差 / 物理环境糟糕情况下，建议你 master 和 slave 均采取 AOF，这个在 master 和 slave 角色切换时，可以减少“人工数据备份”/“人工引导数据恢复”的时间成本；如果你的环境一切非常良好，且服务需要接收密集性的 write 操作，那么建议 master采取 rdb，而 slave 采用 AOF。

redis的过期策略以及内存淘汰机制：比如你redis只能存5G数据，可是你写了10G，那会删5G的数据。怎么删的，这个问题思考过么？还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

在redis.conf中有一行配置：# maxmemory-policy allkeys-lru

该配置就是配内存淘汰策略的

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用。

3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。

4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐

ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

redis中支持事务：支持，使用multi开启事务，使用exec提交事务。

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。Redis 客户端可以订阅任意数量的频道

实现redis高可用机制的一些方法：保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。

主从复制的作用：数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。

主从复制原理：首先主从复制需要分为两个角色：master(主) 和 slave(从) ，注意：redis里面只支持一个主，不像Mysql、Nginx主从复制可以多主多从。

1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

Redis哨兵机制：哨兵机制需要主从复制的支持。

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

· 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

· 提醒(Notification):当被监控的某个Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

· 自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

Nginx

Nginx ("engine x") 是一个高性能的HTTP和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名

常见的应用服务器： Apache/Microsoft IIS/Tomcat/Lighttpd/Nginx

正向代理：意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器

工作原理

Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件将客户端请求映射到一个location block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。

Nginx的模块从结构上分为核心模块、基础模块和第三方模块：

核心模块：HTTP模块、EVENT模块和MAIL模块

基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，

第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

Nginx安装

4.1、编译环境gcc g++ 开发库之类的需要提前装好

　　yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

4.2、首先安装PCRE pcre功能是让nginx有rewrite功能

检查系统里是否安装了pcre软件

　　　　rpm -qa pcre 如果没有显示说明没有安装反之安装过

　　　　rpm -e --nodeps pcre 删除pcre

　　安装pcre：yum install pcre-devel pcre -y

4.3、nginx安装

#下载Nginx源码包

cd /usr/local

wget http://nginx.org/download/nginx-1.9.0.tar.gz

#解压Nginx源码包

tar -zxvf nginx-1.9.0.tar.gz

#进入解压目录，开始安装，默认安装地址 /usr/local/nginx

cd nginx-1.9.0

./configure --prefix=/usr/local/nginx --with-http_ssl_module &&make &&make install

#自此Nginx安装完毕

检查nginx配置文件是否正确，返回OK即正确。

/usr/local/nginx/sbin/nginx -t

#然后启动nginx，

/usr/local/nginx/sbin/nginx 回车即可。

#查看进程是否已启动：

ps aux |grep nginx

4.5 卸载nginx

　　删除nginx文件即可

　　rm -rf /usr/local/nginx

搭建Nginx负载均衡

负载均衡在实际项目操作过程中，有硬件负载均衡和软件负载均衡两种，硬件负载均衡也称为硬负载，如F5负载均衡，相对造价昂贵成本较高，但是数据的稳定性安全性等等有非常好的保障，如中国移动中国联通这样的公司才会选择硬负载进行操作；更多的公司考虑到成本原因，会选择使用软件负载均衡，软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制

nginx支持的负载均衡调度算法方式如下：

weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块
url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意nginx默认不支持这种调度算法，要使用的话需要安装nginx的hash软件包

Nginx 防盗链：比如http://www.dbspread.com/download/av123.rmvb 这个视频下载地址被其他网站引用，比如在www.test.com的index.html引用download/av123.rmvb就叫盗链，我们要禁止这种引用就叫做防盗链

2. 实现防盗链：在nginx的nginx.conf的server里面配置如下代码

server { listen 80; server_name www.dbspread.com *.dbspread.com; location ~* \.(rmvb|jpg|png|swf|flv)$ { #rmvb|jpg|png|swf|flv表示对rmvb|jpg|png|swf|flv后缀的文件实行防盗链 valid_referers none blocked www.dbspread.com; #表示对www.dbspread.com此域名开通白名单，比如在www.test.com的index.html引用download/av123.rmvb,无效 root html/b; if ($invalid_referer) { #如果请求不是从www.dbspread.com白名单发出来的请求，直接重定向到403.html这个页面或者返回403 #rewrite ^/ http://www.dbspread.com/403.html; return 403; } } }

Nginx 动静分离：Nginx动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。

Nginx动静分离应该注意的地方

1). WEB项目开发时要注意，将静态资源尽量放在一个static文件夹

2). 将static静态资源文件夹放到Nginx可以取到的位置

3). 页面要建立全局变量路径，方便修改路径

4). 修改nginx.conf的location，匹配静态资源请求

4. Nginx动静分离步骤

4.1 准备一个静态资源button.css

body { margin: 10px 20px; text-align: center; font-family: Arial, sans-serif; background-color: red; }

4.2 在/var/local下新建一个static文件夹用来存放静态资源button.css

4.3 在tomcat-8080/webapps/ROOT下的index.html里面引入button.css

<html> <head> <link rel="stylesheet" type="text/css" href="http://www.static.com/button.css" /> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <meta name="renderer" content="webkit"> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no"> <title>test</title> </head> <body> 欢迎来到8080端口tomcat </body> </html>

4.4 在nginx的nginx.conf中server节点新增静态资源分离的配置

server { listen 80; #监听80端口 server_name www.dbspread.com; #域名 #rewrite规则 index index.jsp index.html index.htm; root /usr/local/nginx/html; #定义服务器的默认网站根目录位置 #重定向 if ($host != 'www.dbspread.com' ){ rewrite ^/(.*)$ http://www.dbspread.com/$1 permanent; } #防盗链 location ~* \.(rmvb|jpg|png|swf|flv)$ { #rmvb|jpg|png|swf|flv表示对rmvb|jpg|png|swf|flv后缀的文件实行防盗链 valid_referers none blocked www.dbspread.com; #表示对www.dbspread.com此域名开通白名单，比如在www.test.com的index.html引用download/av123.rmvb,无效 root html/b; if ($invalid_referer) { #如果请求不是从www.dbspread.com白名单发出来的请求，直接重定向到403.html这个页面或者返回403 #rewrite ^/ http://www.dbspread.com/403.html; return 403; } } #监听完成以后通过斜杆(/)拦截请求转发到后端的tomcat服务器 location / { #如果后端的服务器返回502、504、执行超时等错误，自动将请求转发到upstream负载均衡池中的另一台服务器，实现故障转移。 proxy_next_upstream http_502 http_504 error timeout invalid_header; proxy_set_header Host $host; #获取客户端的主机名存到变量Host里面,从而让tomcat取到客户端机器的信息 proxy_set_header X-Real-IP $remote_addr; #获取客户端的主机名存到变量X-Real-IP里面,从而让tomcat取到客户端机器的信息 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #rewrite ^/$ http://www.dbspread.com/new.index.html permanent;#用户访问www.dbspread.com，想直接跳转到网站下面的某个页面:www.dbspread.com/new.index.html proxy_pass http://web1; #跳转到对应的应用web1 } # location ~ .*\.(php|jsp|cgi|shtml)?$ #动态分离 ~匹配以.*结尾（以PHP JSP结尾走这段） # { # proxy_set_header Host $host; # proxy_set_header X-Real-IP $remote_addr; # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_pass http://jvm_web2; # } #静态分离 ~匹配以.*结尾（以html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css结尾走这段），当然不是越久越好，如果有10000个用户在线，都保存几个月，系统托跨 location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ { root /var/local/static; #静态资源存放在nginx的安装机器上 #proxy_pass http://www.static.com; #静态资源也可存放在远程服务器上 expires 30d; #30天之内只要访问过一次就从缓存拿 } #日志级别有[debug|info|notice|warn|error|crit] error_log 级别分为 debug, info, notice, warn, error, crit 默认为crit, 生产环境用error #crit 记录的日志最少,而debug记录的日志最多 access_log /usr/local/logs/web2/access.log main; error_log /usr/local/logs/web2/error.log crit; }

Nginx+keepalived 实现高可用

1. keepalived是什么

Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件

2. keepalived主要功能

管理LVS负载均衡软件

实现LVS集群节点的健康检查

作为系统网络服务的高可用性（failover）

3. keepalived故障转移

Keepalived高可用服务之间的故障切换转移，是通过 VRRP 来实现的。

在 Keepalived服务正常工作时，主 Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的 IP资源及服务。而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

说明：keepalived的主从切换和redis的主从切换是不一样的，keepalived的主节点挂了以后，从节点变为主节点，之前的主节点恢复以后继续做主节点。redis的主节点挂了以后，重新恢复以后变为从节点

4. keepalived高可用架构示意图

Solr

Solr它是一种开放源码的、基于 Lucene Java 的搜索服务器，易于加入到 Web 应用程序中。Solr 提供了层面搜索(就是统计)、命中醒目显示并且支持多种输出格式（包括XML/XSLT 和JSON等格式）。它易于安装和配置，而且附带了一个基于 HTTP 的管理界面。Solr已经在众多大型的网站中使用，较为成熟和稳定。Solr 包装并扩展了 Lucene，所以Solr的基本上沿用了Lucene的相关术语。更重要的是，Solr 创建的索引与 Lucene 搜索引擎库完全兼容。通过对Solr 进行适当的配置，某些情况下可能需要进行编码，Solr 可以阅读和使用构建到其他 Lucene 应用程序中的索引。

Lucene是一个基于Java的全文信息检索工具包，它不是一个完整的搜索应用程序，而是为你的应用程序提供索引和搜索功能。Lucene 目前是 Apache Jakarta(雅加达) 家族中的一个开源项目。也是目前最为流行的基于Java开源全文检索工具包。

Solr与Lucene 并不是竞争对立关系，恰恰相反Solr 依存于Lucene，因为Solr底层的核心技术是使用Lucene 来实现的，Solr和Lucene的本质区别有以下三点：搜索服务器，企业级和管理。Lucene本质上是搜索库，不是独立的应用程序，而Solr是。Lucene专注于搜索底层的建设，而Solr专注于企业应用。Lucene不负责支撑搜索服务所必须的管理，而Solr负责。所以说，一句话概括 Solr: Solr是Lucene面向企业搜索应用的扩展。

安装虚拟机（java1.6版本或以上）、下载Sorlr、下载并设置Apache Ant、配置并运行Solr代码

基本配置：

模式配置Schema.xml

types 部分

是一些常见的可重用定义，定义了 Solr（和 Lucene）如何处理 Field。也就是添加到索引中的xml文件属性中的类型，如int、text、date等.<fieldType name="boolean" class="solr.BoolField" sortMissingLast="true"/>

fileds：是你添加到索引文件中出现的属性名称，而声明类型就需要用到上面的types

solr配置solrconfig.xml

查询配置query

Solr加入中文分词器：. smartcn 分词器的安装、 IK 分词器的安装

Solr功能应用：这里主要使用SolrJ进行介绍一下Solr的一些基本应用,使用SolrJ加上EmbeddedSolrServer(嵌入式服务器),方便进行代码跟踪调试.在功能上和其它服务器都是一样的,它们都是继承的SolrServer来提供服务API的. EmbeddedSolrServer优点是不用起http协议,直接加载SolrCore进行操作,性能上应该是最快的,方便用于把Solr单结点服务嵌入到项目中使用.

维护索引：在一般系统中维护的都是增删改,在Solr中的维护功能是增删和优化功能,在Solr中的修改操作就是先删掉再添加.在做索引维护之前,首先要做的是配置schema.xml主要是按上面章节中的说明设置好字段信息(名称,类型,索引,存储,分词等信息),大概就像在数据库中新建一个表一样.设置好schema.xml就可以进行索引相关操作了.

增加索引：在增加索引之前先可构建好SolrInputDocument对象.主要操作就是给文档添加字段和值.

SolrInputDocument doc = new SolrInputDocument();

doc.setField("id", "ABC");

doc.setField("content", "中华人民共和国");

删除索引：删除索引可以通过两种方式操作,一种是通过文档ID进行删除（server.deleteById(id)）,别一种是通过查询到的结果进行删除.（server.deleteByQuery("*.*");）

通过ID删除方式代码:

优化索引：优化Lucene 的索引文件以改进搜索性能。索引完成后执行一下优化通常比较好。如果更新比较频繁，则应该在使用率较低的时候安排优化。一个索引无需优化也可以正常地运行。优化是一个耗时较多的过程。（server.optimize();）

文本检索：Solr在不修改任务配置的情况下就可以使用文本检索功能，在web项目中应用可以直接URL进行访问Solr服务器例如：（

http://localhost:8983/solr/ collection1/select?q=*%3A*&wt=xml&indent=true）

查询参数

名称	描述
q	查询字符串，必须的。
fq	filter query。使用Filter Query可以充分利用Filter Query Cache，提高检索性能。作用：在q查询符合结果中同时是fq查询符合的，例如：q=mm&fq=date_time:[20081001 TO 20091031]，找关键字mm，并且date_time是20081001到20091031之间的。
fl	field list。指定返回结果字段。以空格“ ”或逗号“,”分隔。
start	用于分页定义结果起始记录数，默认为0。
rows	用于分页定义结果每页返回记录数，默认为10。
sort	排序，格式:sort=<field name>+<desc\|asc>[,<field name>+<desc\|asc>]… 。示例：（inStock desc, price asc）表示先 “inStock” 降序, 再 “price” 升序，默认是相关性降序。
df	默认的查询字段，一般默认指定。
q.op	覆盖schema.xml的defaultOperator（有空格时用"AND"还是用"OR"操作逻辑），一般默认指定。必须大写
wt	writer type。指定查询输出结构格式，默认为“xml”。在solrconfig.xml中定义了查询输出格式：xml、json、python、ruby、php、phps、custom。
qt	query type，指定查询使用的Query Handler，默认为“standard”。
explainOther	设置当debugQuery=true时，显示其他的查询说明。
defType	设置查询解析器名称。
timeAllowed	设置查询超时时间。
omitHeader	设置是否忽略查询结果返回头信息，默认为“false”。
indent	返回的结果是否缩进，默认关闭，用 indent=true\|on 开启，一般调试json,php,phps,ruby输出才有必要用这个参数。
version	查询语法的版本，建议不使用它，由服务器指定默认值。
debugQuery	设置返回结果是否显示Debug信息。

查询语法

函数查询：1. 使用函数查询的方法

这里主要有三种方法可以使用函数查询，这三种s方法都是通过solr http接口的。

1) 使用FunctionQParserPlugin。ie: q={!func}log(foo)

2) 使用“_val_”内嵌方法

内嵌在正常的solr查询表达式中。即，将函数查询写在 q这个参数中，这时候，我们使用“_val_”将函数与其他的查询加以区别。

ie：entryNm:make && _val_:ord(entryNm)

3) 使用dismax中的bf参数

使用明确为函数查询的参数，比如说dismax中的bf（boost function）这个参数。注意：bf这个参数是可以接受多个函数查询的，它们之间用空格隔开，它们还可以带上权重。所以，当我们使用bf这个参数的时候，我们必须保证单个函数中是没有空格出现的，不然程序有可能会以为是两个函数。

高亮显示：solr 默认已经配置了highlight 组件(详见 SOLR_HOME/conf/sorlconfig.xml)。通常我出只需要这样请求http://localhost:8983/solr/ collection1 /select? q=%E4%B8%AD%E5%9B%BD&start=0&rows=1&fl=content+path+&wt=xml&indent=true&hl=true&hl.fl=content

可以看到与比一般的请求多了两个参数 "hl=true" 和 "hl.fl= content " 。

"hl=true" 是开启高亮，"hl.fl= content " 是告诉solr 对 name 字段进行高亮(如果你想对多个字段进行高亮，可以继续添加字段，字段间用逗号隔开，如 "hl.fl=name,name2,name3")。高亮内容与关键匹配的地方，默认将会被 "<em>" 和 "</em>" 包围。还可以使用hl.simple.pre" 和 "hl.simple.post"参数设置前后标签.

拼写检查：首先配置 solrconfig.xml，文件可能已经有这两个元素(如果没有添加即可)，需要根据我们自己的系统环境做些适当的修改。

<str name="queryAnalyzerFieldType">text_spell</str>

<str name="name">direct</str>

<str name="field">spell</str>

<str name="classname">solr.DirectSolrSpellChecker</str>

<str name="distanceMeasure">internal</str>

</lst>

</searchComponent>

<str name="spellcheck.dictionary">direct</str>

</lst>

<str>spellcheck</str>

</arr>

</requestHandler>

检索建议：检索建议目前是各大搜索的标配应用，主要作用是避免用户输入错误的搜索词，同时将用户引导到相应的关键词搜索上。Solr内置了检索建议功能，它在Solr里叫做Suggest模块.该模块可选择基于提示词文本做检索建议，还支持通过针对索引的某个字段建立索引词库做检索建议。

<str name="queryAnalyzerFieldType">string</str>

<str name="name">suggest</str>

<str name="classname">org.apache.solr.spelling.suggest.Suggester</str>

<str name="lookupImpl">org.apache.solr.spelling.suggest.tst.TSTLookup</str>

<str name="spellcheckIndexDir">spellchecker</str>

</lst>

</searchComponent>

<str name="spellcheck.dictionary">suggest</str>

<str name="spellcheck.extendedResults">false</str>

</lst>

<str>suggest</str>

</arr>

</requestHandler>

分组统计、自动聚类、相似匹配、拼音检索

SolrCloud：SolrCloud是基于Solr和Zookeeper的分布式搜索方案，是正在开发中的Solr4.0的核心组件之一，它的主要思想是使用Zookeeper作为集群的配置信息中心。它有几个特色功能,集中式的配置信息、自动容错、近实时搜索、查询时自动负载均衡。

基本可以用上面这幅图来概述，这是一个拥有4个Solr节点的集群，索引分布在两个Shard里面，每个Shard包含两个Solr节点，一个是Leader节点，一个是Replica节点，此外集群中有一个负责维护集群状态信息的Overseer节点，它是一个总控制器。集群的所有状态信息都放在Zookeeper集群中统一维护。从图中还可以看到，任何一个节点都可以接收索引更新的请求，然后再将这个请求转发到文档所应该属于的那个Shard的Leader节点，Leader节点更新结束完成，最后将版本号和文档转发给同属于一个Shard的replicas节点。

Dubbo

是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

可用场景：

1，商城做活动流量暴涨：防止系统崩掉可以通过dubbo来控制访问量

2，分布式服务器rpc过程调用压力分担

1.服务化应用基本框架:服务提供者启动，根据协议信息绑定到配置的IP和端口上，如果已有服务绑定过相同IP和端口的则跳过

注册服务信息至注册中心
客户端启动，根据接口和协议信息订阅注册中心中注册的服务，注册中心将存活的服务地址通知到客户端，当有服务信息变更时客户端可以通过定时通知得到变更信息
在客户端需要调用服务时，从内存中拿到上次通知的所有存活服务地址，根据路由信息和负载均衡机制选择最终调用的服务地址，发起调用
通过filter分别在客户端发送请求前和服务端接收请求后，通过异步记录一些需要的信息传递到monitor做监控或者统计

服务接口定义

一般单独有一个jar包，维护服务接口定义、RPC参数类型、RPC返回类型、接口异常、接口用到的常量，该jar包中不处理任何业务逻辑。

注册中心

开源的dubbo已支持4种组件作为注册中心，我们部门使用推荐的zookeeper做为注册中心，由于就瓶颈来说不会出现在注册中心，风险较低，未做特别的研究或比较。

zookeeper，推荐集群中部署奇数个节点，由于zookeeper挂掉一半的机器集群就不可用，所以部署4台和3台的集群都是在挂掉2台后集群不可用
redis
multicast,广播受到网络结构的影响，一般本地不想搭注册中心的话使用这种调用
dubbo简易注册中心

对于zookeeper客户端，dubbo在2.2.0之后默认使用zkclient，2.3.0之后提供可选配置Curator，提到这个点的原因主要是因为zkclient发现一些问题：①服务器在修改服务器时间后zkClient会抛出日志错误之类的异常然后容器（我们使用resin）挂掉了，也不能确定就是zkClient的问题，接入dubbo之前无该问题②dubbo使用zkclient不传入连接zookeeper等待超时时间，使用默认的Integer.MAX_VALUE，这样在zookeeper连不上的情况下不报错也无法启动；目前我们准备寻找其他解决方案，比如使用curator试下，还没正式投入。

监控中心

如果使用Dubbo自带的监控中心，可通过简单配置即可，先通过github获得dubbo-monitor的源码，部署启动后在应用配置如下

[html] view plain copy

<dubbo:monitor protocol="registry" />

[html] view plain copy

<dubbo:monitor address="dubbo://127.0.0.1:7070/com.alibaba.dubbo.monitor.MonitorService" />

Dubbo框架设计一共划分了10个层

服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、 Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和 Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

负载均衡

dubbo提供4种负载均衡方式:

Random，随机，按权重配置随机概率，调用量越大分布越均匀，默认是这种方式
RoundRobin，轮询，按权重设置轮询比例，如果存在比较慢的机器容易在这台机器的请求阻塞较多
LeastActive，最少活跃调用数，不支持权重，只能根据自动识别的活跃数分配，不能灵活调配
ConsistentHash，一致性hash，对相同参数的请求路由到一个服务提供者上，如果有类似灰度发布需求可采用

dubbo的负载均衡机制是在客户端调用时通过内存中的服务方信息及配置的负责均衡策略选择，如果对自己系统没有一个全面认知，建议先采用random方式。

dubbo过滤器

有需要自己实现dubbo过滤器的，可关注如下步骤：

dubbo初始化过程加载META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个路径(classloaderresource)下面的com.alibaba.dubbo.rpc.Filter文件
文件配置每行Name=FullClassName，必须是实现Filter接口
@Activate标注扩展能被自动激活
@Activate如果group（provider|consumer）匹配才被加载
@Activate的value字段标明过滤条件，不写则所有条件下都会被加载，写了则只有dubbo URL中包含该参数名且参数值不为空才被加载

如下是dubbo rpc access log的过滤器，仅对服务提供方有效，且参数中需要带accesslog，也就是配置protocol或者serivce时配置的accesslog="d:/rpc_access.log"

返克

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫