基于Docker的Redis入门与实战(1).docx

《基于Docker的Redis入门与实战(1).docx》由会员分享，可在线阅读，更多相关《基于Docker的Redis入门与实战(1).docx（5页珍藏版）》请在第一文库网上搜索。

1、通过第1行和第2行的代码，指定了本下单微服务模块工作在5555端口；通过第3行和第5行的代码，指定了本项目的对外服务名。本项目是EUreka客户端，需要向EUreka服务器注册，所以需要编写从第6行到第11行的代码。通过第13行到第15行的代码，指定了本项目用到的Redis服务器地址和端口。编写完上述代码后,可以通过如下的步骤观察运行效果，从而验证RediS缓存的效果。步骤O1I通过dockerStart命令，启动表13.4里所述的相关MySQ1和RediS容器，以确保MySQ1和Redis处于运行状态。步骤02启动EUreka服务器和风控模块的EUreka客户端，并运行本项目里的EUreka

2、C1ientFOrPay1nentAPP.java程序，启动本下单微服务模块。启动后，在浏览器里输入a1oca1host:8888,能在EUreka控制台的Instancescurrent1yregisteredwithEurekaw部分里看到注册到EUreka服务器的两个微服务EUreka客户端。在此基础上，下单模块才能通过EUreka服务器找到风控模块并调用其中的方法，具体效果如图13.9所示。图13.9在EUreka服务器上观察到的微服务模块效果图步骤03在浏览器里输入“http:/IOCaIhoSt:5555/CanPay/003”,能在页面上看到003cannotPayduetoHi

3、ghRisk.,的字样。多次输入该Ur1,除了能看到相同的文字之外，还能在JaVa控制台里看到“GetFromRedisw的字样，这说明本下单微服务模块也会用Redis缓存中风控模块的结果，以此有效降低风控模块的负载。步骤04I在浏览器里输入“http:IOCaIhOSt:5555/CanPay/001”，则能看到输出的文字是“001canPay。多次输入该ur1,同样能在JaVa控制台里看到GetFromRedis”的字样。这里在风控数据表里没有记录USer1D为OO1的数据，所以下单模块向风控模块查询此用户的风控信息时得到的始终是空数据，但依然需要在RediS里缓存这些空数据。如果不缓存，

4、那么遇到此类“在风控数据表里不存在的USerID”时，下单模块依然会一次又一次地向风控模块发请求。如果并发量很高，那么这些请求会压垮风控模块的数据库乃至整个风控模块，所以这种“在RediS里缓存空数据”的做法能在下单模块通过RediS缓存过滤掉部分请求，从而对风控模块起到一定的保护作用。13.3Redis与Ribbon整合使用在SPringCIOUd全家桶组件里，可以用RibbOn组件来实现负载均衡。具体地，在微服务体系的项目里，可以把功能相同的组件部署在多个服务器上，用Ribbon把请求分摊到这些功能相同的模块上，并且这些模块一般情况下是共享RCdiS组件或者集群，从而用缓存的方式来提升数据

5、访问性能。13.3.1Ribbon负载均衡组件与Redis的整合效果RibbOn是SPringC1OUd全家桶里负责负载均衡的组件，通过使用该组件，开发者可以在不用过多考虑细节的基础上实现负载均衡的效果。具体而言，在某包含RibbOn组件的微服务体系里，某服务(比如前文提到的风控模块)可以在多台服务器上部署，当服务使用者(比如下单模块)多次发起服务请求时，这些请求能被合理地均摊到多台服务器上。Ribbon组件支持如下两种常用的负载均衡策略。(1)轮询策略，即把请求依次派发到多个服务器上。(2)随机策略，即随机地把请求发送到多台服务器上。事实上，在13.2.5节下单微服务的EurekaC1ien

6、tForPaymentApp.java程序里，通过如下的代码定义了RestTemp1ate类型的对象，其中加入了第2行的1oadBa1anCed注解，所以会用到RibbOn组件，以负载均衡的方式去请求数据。只不过当时风控模块只部署在一台服务器上，所以看不到负载均衡的效果。O1Bean021oadBa1anced03pub1icRestTemp1ategetRestTemp1ate()04returnnewRestTemp1ateO；05)在本节里，将在本机不同的端口上运行两个风控模块，从而模拟在两台服务器上部署风控模块的效果。定此基础上，如果根据评估发现单个RediS集群足以应对系统可能会遇到

7、的并发量，就可以让这两个风控模块共享同一个RCdiS集群，具体效果如图13.10左边的子图所示。如果单个RCdiS不足以应对并发量，就可以让各风控微服务组件使用独立的RediS节点(或集群)，从而降低缓存层面的压力，具体效果如图13.10右边的子图所示。PediS缓存RediS缓存1RediS缓存图13.10以两种方式整合Redis的效果图13.3.2引入多个风控组件分摊流量根据上文的设计，这里用负载均衡的方式部署两个风控微服务组件，而下单模块发出的请求会通过Ribbon组件均摊到这两个风控模块上，同时这两个风控模块将共享Redis缓存组件。在表13.5里，大家能看到该RediS整合RibbO

8、n微服务体系里的相关项目。表13.5风控项目关键文件一览表项目名作用说WEurckaScrvcrEurcka版分器代码和1323琳里的同名项目完全一致RiskProj-nodeI风控微服务模块和13.2.4方里的RiskPE项目很相似.工作在1122端口.服务名I是RiskScncr.整介Rcdis组件作缓存RtskProj-node2风控微服务模块和1324里的RiskProj项目极相帆I：作上1133端II.服务名是RiskScncr.整合Rcdis组件作缓存PaymcntProj卜的微服务模块代码和”25节里的同名项IJ完全致,通过RibbOn纲件以负我均衡的方式访问两个风控模块，整介R

9、EiS组件作级存EurekaServer和PaymentProj项目可以沿用之前的，RiskProj-node1和RiskProj-node2项目与RiSkProj很相似，但需要做如下两点修改。修改点1:在RiSkProj-node1项目控制器类COntroIIer.java里，如第7行所示，加入一句输出语句，以表示是由RiskProj-node1风控模块处理的请求。O1RestContro11er02pub1icc1assContro11er03AUtoWired04privateRiskServiceriskService;05RequestMapping(,VgetRiskByUserI

10、D/userID,)06ub1icStringgetRiskByUserID(PathVariab1eStringuserID)07System,out.print1n(z,FromRiskProj-node1*);08returnriskService.getRiskByUserID(userID);0910)在RiskProj-node2项目控制器类Contro11er.java里，也需要在相同位置加入如下的输出语句。System.out.printIn(zzFromRiskProj-node1);这样当下单模块发出请求时就会被均衡地发送到两个风控微服务模块上。修改点2：修改RiSkPrO

11、j-node1项目app1ication.ym1里关于端口的配置(项目工作在1122端口)。修改后的代码如下。O1server:02port:1122同时也要修改RiSkProj-node2项目app1ication.ym1里关于端口的配置(项目工作在1133端口)，修改后的代码如下。O1server:02port:1133注意，需要确保这两个项目依然用RiSkSerVer对外提供服务。O1spring:02app1ication:03name:RiskServer如果RiskProj-node1和RiskProj-node2共享Redis缓存，那么Redis相关配置在app1ication,

12、ym1文件里维持原样。如果要通过增加RediS组件来减轻缓存压力，就可以在RiskProj-node2项目的app1ication,ym1里做类似如下的修改，让它使用其他Redis服务器。01redis:02host:1oca1host03port:638013.3.3从缓存和负载均衡维度观察整合后的效果完成代码修改后，能通过如下的步骤观察到在SPringCIOUd微服务体系里RCdiS整合Ribbon的效果。步骤O1步骤02确保表13.4里所述的相关MySQ1和Redis容器处于运行状态。依次启动EUrekaSerVer、RiskProj-node1RiSkPrOj-node2和Payine

13、ntPrOj这四个微服务项目。其中，EurekaServer是Eureka服务器，另外三个是向Eureka服务器注册的Eureka客户端。同时，RiskProj-node1RiskProj-node2和PaymentProj这三个项目里都要整合RediS组件。启动完成后，在IoCaIhoSt:8888所在的EUreka服务器控制台的“Instancescurrent1yregisteredwithEUreka”下面能看到三个EUreka客户端信息（见图13.11）,说明上述服务器正确启动。图13.11EUreka客户端效果图步骤03在浏览器里依次输入http:IOCaIhOSt:5555/Ca

14、nPay/020”和uhttp:/1oca1host:5555/CanPay/030”等请求，除了能在浏览器里正确地看到返回结果以外，还能在相关的JaVa控制台里看到FromRiskProj-node1,和FromRiskProj-node2字样，说明下单模块对风控的请求被RibbOn组件均摊到两个风控微服务模块上。由此大家能看到“负载均衡”的效果。步骤04在第三步的基础上继续在浏览器里输入“http:IoCaIhOSt:5555/CanPay/020”和http:IoCa1hoSt:5555/CanPay/030”请求，发现在Payment_Proj项目的JaVa控制台里有“GetFromR

15、cdis”的输出，说明下单模块向风控模块发值的请求被RediS组件很好地缓存起来，之后的请求可以直接从RediS缓存里得到结果，而无须再向风控微服务模块请求数据。也就是说，当RediS和SPringC1OUd全家桶里RibbOn和EUreka等组件整合以后，能从“缓存”和“负载均衡”这两个维度应对高并发的压力，可以有效地降低高并发对数据库和相关微服务组件的负载压力。13.4本章小结本章在介绍微服务体系架构的基础上给出了Redis整合微服务的多个案例，具体地讲就是给出了RediS整合SPringC1OUd全家桶里EUreka和Ribbon等组件的案例。通过这些案例，大家可以知道Redis组件在微服务体系架构中能更好地发挥缓存的作用、能和其他微服务组件一起更好地应对高并发的挑战。