三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。
四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。
TCP三次握手、四次挥手时序图
TCP协议位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP协议采纳三次握手策略。
三次握手原理：
第1次握手：客户端发送一个带有SYN（synchronize）标志的数据包给服务端；
第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了；
第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。
其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。
可通过以下趣味图解理解三次握手：
三次握手过程详细说明：
1、客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）；
2、服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；
3、客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
四次挥手原理：
第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态；
第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态；
第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态；
第4次挥手：客户端收到FIN后，客户端t进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。
其中：FIN标志位数置1，表示断开TCP连接。
可通过以下趣味图解理解四次挥手：
四次挥手过程详细说明：
1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）；
2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）；
3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）；
4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）
至此TCP断开的4次挥手过程完毕。
LISTEN：等待从任何远端TCP 和端口的连接请求。
SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。
SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。
FIN_WAIT_2：等待远端TCP 的连接终止请求。
CLOSE_WAIT：等待本地用户的连接终止请求。
CLOSING：等待远端TCP 的连接终止请求确认。
LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认）
TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。
TIME_WAIT 两个存在的理由：
1可靠的实现tcp全双工连接的终止；
2允许老的重复分节在网络中消逝。
CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）。TTI Bundling是一种上行链路覆盖提升技术，即连续4个子帧发送不同的RV；而ACK Bundling是解决TD-LTE中上行反馈资源受限的问题，即多个ACK在同一个上行子帧内反馈。
这两者没有必然的联系。1 TD-LTE路测中对于掉线的定义如何，掉线率指标是指什么？
掉线的定义为测试过程中已经接收到了一定数据的情况下，超过3分钟没有任何数据传输。掉线率=各制式掉线次数总和/(成功次数+各制式掉线次数总和)
2 LTE的测量事件有哪些？
同系统测量事件：
A1事件：表示服务小区信号质量高于一定门限；
A2事件：表示服务小区信号质量低于一定门限；
A3事件：表示邻区质量高于服务小区质量，用于同频、异频的基于覆盖的切换；
A4事件：表示邻区质量高于一定门限，用于基于负荷的切换，可用于负载均衡；
A5事件：表示服务小区质量低于一定门限并且邻区质量高于一定门限，可用于负载均衡;
异系统测量事件：
B1事件：邻小区质量高于一定门限，用于测量高优先级的异系统小区；
B2事件：服务小区质量低于一定门限，并且邻小区质量高于一定门限，用于相同或较低优先级的异系统小区的测量。
3 UE在什么情况下听SIB1消息？
SIB1的周期是80ms，触发UE接收SIB1有两种方式，一种方式是每周期接收一次，另一种是UE收到paging消息，由paging消息所含的参数得知系统信息有变化，然后接收SIB1，SIB1消息会通知UE是否继续接收其他SIB。
4 随机接入通常发生在哪5 种情况中？
a) 从RRC_IDLE 状态下初始接入。
b) RRC 连接重建的过程。
c) 切换。
d) RRC_CONNECTED 状态下有下行数据自EPC（核心网）来需要随机接入时。
e) RRC_CONNECTED 状态下有上行数据至EPC 而需要随机接入时。
5 LTE上行为什么要采用SC-FDMA技术？
考虑到多载波带来的高PAPR（峰值平均功率比）会影响终端的射频成本和电池寿命。最终3GPP决定在上行采用单载波频分复用技术SC-FDMA中的频域实现方式DFT-S-OFDM。可以看出与OFDM不同的是在调制之前先进行了DFT（离散傅里叶变换）的转换，这样最终发射的时域信号会大大减小PAPR。这种处理的缺点就是增加了射频调制的复杂度。实际上DFT-S-OFDM可以认为是一种特殊的多载波复用方式，其输出的信息同样具有多载波特性，但是由于其有别于OFDM的特殊处理，使其具有单载波复用相对较低的PAPR特性。
6 在TD-LTE网络测试过程中，我们主要关注的指标参数有哪些？请写出缩写名称及解释
PCI，RSRP参考信号接收功率,RSRQ参考信号接收质量,SINR等
7 列出天线的其中四项主要电气参数？
天线增益，频带宽度，极化方向，波瓣角宽度，前后比，最大输入功率，驻波比，三阶互调，天线口隔离度
8 请描述“水面覆盖—法线方向水面拉远测试_在下行业务开启下进行水面拉远”这一测试，需要记录哪些测试数据？输出哪些曲线图？（说出至少5项测试数据，2项曲线图）
a) 记录ENB的信息，站高，天线角，下倾角，发射功率； 记录断点处UE与ENB的距离。
b) 绘制水面覆盖RSRP，SINR，L3吞吐量随距离变化曲线；
c) 绘制船只行驶路线的RSRP,SINR覆盖及拉远距离。
9 在定点测试—法线方向好中差定点上下行吞吐量测试”中“好点，中点，差点”定义的SINR和RSRP一般分别是多少？
好点RSRP高于-75dbm，SINR [15,20]db,中点RSRP [-80,-95]dbm，SINR [5,10]db；差点RSRP低于-100dbm，SINR[-5,0]db
10 eNodeB 根据UE 上报的信令计算出TA，只有在需要调整TA 时下指令给UE 调整，已知需要调整的时间粒度为16Ts，计算这个时间对应的空间距离变化是多少？（注意此时间包含了UE 上报/ENodeB 指配双程的时间）。
Ts=1/(15000·2048)=1/3072000，约为00326μs。则16Ts约为052μs。单程的时间为026μs。此时间段内对应无线电波的速率，UE 的空间距离变化约为78 米。
11 随机接入通常发生在哪几种情况中？
1． 从RRC_IDLE 状态下初始接入
2． RRC 连接重建的过程
3． 切换
4． RRC_CONNECTED 状态下有下行数据且上行失步
5． RRC_CONNECTED 状态下有上行数据且上行失步
6． RRC_CONNECTED 状态下ENB需要获取TA信息，辅助定位
12 TM3（开环空分复用）和TM4（闭环空分复用）这两种传输模式下，UE上报信息的区别是什么？
TM3模式下UE上报CQI、RI;
TM4模式下UE上报CQI（信道质量指示）、RI（秩指示）、PMI（预编码矩阵指示）。
13 请简述LTE的CP（前缀）的作用，设计原则和类型。
在LTE系统中，为了消除多经传播造成的符号间干扰，需要将OFDM符合进行周期扩展，在保护间隔内发送循环扩展信号，成为循环扩展前缀CP。过长的CP会导致功率和信息速率的损失，过短的CP无法很好的消除符合间干扰。当循环前缀的长度大于或等于信道冲击响应长度时，可以有效地消除多经传播造成的符号间干扰。
CP是将OFDM符号尾部的信号搬到头部构成的。
LTE系统支持2类CP，分别是Normal CP（循环前缀）和Extended CP（扩展循环前缀）。
14 简述触发LTE系统内切换的主要事件及含义
Event A1：服务小区测量值（RSRP 或RSRQ）大于门限值 ；
Event A2：服务小区测量值（RSRP 或RSRQ）小于门限值 ；
Event A3：邻小区测量值优于服务小区测量值一定门限值
Event A4：邻小区测量值大于门限值
Event A5：服务小区测量值小于门限1，同时邻小区信道质 量大于门限2
15 衡量LTE覆盖和信号质量基本测量量是什么？
LTE中最基本，也是日常测试中关注最多的测量有四个：
1）RSRP(Reference Signal Received Power)主要用来衡量下行参考信号的功率，可以用来衡量下行的覆盖。
2）RSRQ (Reference Signal Received Quality)主要衡量下行特定小区参考信号的接收质量。
3）RSSI(Received Signal Strength Indicator)指的是手机接收到的总功率，包括有用信号、干扰和底噪
4）SINR(Signal-to-Interference plus Noise Ratio)信号干扰噪声比，指接收到的有用信号的强度与干扰信号（干扰加噪声）强度的比值
16 请简述TDLTE小区下行三种UE资源分配优先调度技术的优缺点？
轮询调度：一个接一个的为UE服务
优点：实现简单，保证用户的时间公平性
缺点：不考虑信道状态，恶劣无线条件下的UE将会重发，从而降低小区的吞吐量
最大C/I调度算法：无线条件最好的UE将优先得到服务（最优CQI）
优点：提高了有效吞吐量（较少的重发）
缺点：恶劣无线条件下的UE永远得不到服务，公平性差
比例公平算法：为每个用户分配相应的优先级，优先级最大的用户提供服务
优点：所有UE都可以得到服务，系统吞吐量较高，是用户公平性和小区吞吐量的折中
缺点：需要跟踪信道状态，算法复杂度较高
17 请简单解释TDLTE中PDSCH使用的两个功率偏置参数的含义及对应22MIMO的子帧内符号位置（PDCCH占用2个符号，范围0-13）？
paOffsetPdsch：是没有RS的PDSCH RE的发射功率偏置，对应子帧内符号2,3,5,6,8,9,10,12,13
pbOffsetPdsch：是有RS的PDSCH RE的发射功率偏置，对应子帧内符号4,7,11
18 简述TD-LTE系统中基于竞争的随机接入流程。
基于竞争的随机接入是指eNodeB没有为UE分配专用Preamble码，而是由UE随机选择Preamble码并发起的随机接入。竞争随机接入过程分4步完成，每一步称为一条消息，在标准中将这4步称为Msg1-Msg4。
1、 Msg1：发送Preamble码
2、 Msg2：随机接入响应
3、 Msg3: 第一次调度传输
4、 Msg4：竞争解决
19 请简述当进行多邻区干扰测试，在天线传输模式为DL：TM2/3/7自适应情况下，各种模式的应用场景。
1如果天线为MIMO天线，在CQI高的情况下，采用TM3传输模式，下行采用双流，峰值速率增加；
2天线为BF天线，且CQI无法满足TM3时，采用TM7；
3如果天线不支持BF,但支持MIMO，在CQI高的情况下采用TM3，CQI低的情况下采用TM2。
20 进行簇优化时，如何利用扫频仪的测试结果对区域的覆盖/干扰情况做总体判断？
利用扫频仪对特定频点的测试结果可以得到电平/信噪比分布统计，理想的分布是尽量高比例的打点分布于高电平/高信噪比的区域，如果打点集中分布于低电平/低信噪比的区域，说明区域有明显的弱覆盖问题，如果打点集中分布于高电平/低信噪比的区域，则说明区域需要解决信号的相互干扰问题。
21 路测中常见的几个T300系列的Timer分别表示什么？
T300：RRC连接建立的定时器，从UE发送MSG1开始计时，到收到RRCConnectionSetup或RRCConnectionReject结束，如果在定时器定义的周期内未收到则记为T300超时；
T301：RRC重建的定时器，从UE发送MSG1开始计时，到收到RRCConnectionReestablishment或RRCConnectionReestablishmentReject结束，如果在定时器定义的周期内未收到则记为T301超时;
T304：切换定时器，从UE收到RRCConnectionReconfiguration（含MobilityControlINfo）开始，到UE完成切换发送RRCConnectionReconfigurationComplete结束，如果在定时器定义的周期内未收到则记为T304超时。
22 工程师在现场优化时为控制覆盖，对1个使用两通道天线的小区进行了降功率6db *** 作（调整powerscaling），达到了预期的目标，该小区两个通道的PMAX均为10w，在sib2中收到的Referfencesignalpower为12dbm，pb=1；RRCconnctionsetup中收到的pa=0。请简述这一 *** 作的不良后果。
在平均功率分配的条件下（pa=0，pb=1），10W两通道小区满功率发射时的RS信号功率为10log(10000)+10log(1+1)-10lg1200=122dbm，说明降功率的手段没有反应在广播消息中，而实际RSRP下降6db，会造成路损估计过大，在开环功控阶段会造成UE发射功率过大，产生上行干扰，影响网络性能或eNB异常，比如prach功率过大告警。
23 请简述TD-LTE中的ACK/NACK捆绑模式（ACK/NACK Bundling）和ACK/NACK复用模式（ACK/NACK Mutiplexing）之间的差别。
在TD-LTE中，当一个上行子帧需要ACK多个下行子帧时，ACK/NACK捆绑模式是指将多个下行子帧的某个码字的所有ACK/NACK使用“与”的方式得到该码字的一个Bundled ACK/NACK比特，2个码字对应2个Bundled ACK/NACK比特；而ACK/NACK复用模式是指先对每个下行子帧中2个码字的ACK/NACK使用“与”的方式得到该子帧的一个Spatial Bundled ACK/NACK比特（Spatial Bundling），然后将所有下行子帧的Spatial Bundled ACK/NACK比特级联在一起得到一个ACK/NACK序列。
24 简要介绍LTE中小区搜索的过程
1）频点扫描：UE开机后，在可能存在LTE小区的几个中心频点上接收信号主同步信号PSS，以接收信号强度来判断这个频点周围是否可能存在小区，如果UE保存了上次关机时的频点和运营商信息，则开机后会先在上次驻留的小区上尝试；若没有，就要在划分给LTE系统的频带范围作全频段扫描，发现信号较强的频点去尝试接收PSS
2）时隙同步：PSS占用中心频点的6RB，因此可直接检测并接收到。据此可得到小区组里小区ID，同时确定5ms的时隙边界，并可通过检查这个信号就可以知道循环前缀的长度以及采用的是FDD还是TDD（因为TDD的PSS防止位置有所不同；
3)帧同步：在PSS基础上搜索辅助同步信号SSS，SSS有两个随机序列组成，前后半帧的映射正好相反，故只要接收到两个SSS，就可确定10ms的帧边界，同时获取小区组ID，跟PSS结合就可以获取CELL ID；
4）PBCH获取：获取帧同步后，就可以读取PBCH了，通过解调PBCH，可以获取系统帧号、带宽信息以及PHICH的配置、天线配置等重要信息；
5）SIB获取：然后UE要接收在PDSCH上承载的BCCH信息。此时该信道上的时频资源就是已知的了，在控制区域内，除去PCFICH和PHICH信道资源，搜索PDCCH并做译码。用SI-RNTI检测出PDCCH信道中的内容，得出PDSCH中SIB的时频位置，译码后将SIB告知高层协议，高层会判断接收的系统消息是否足够，如果足够则停止接收SIB。
25 请简述可能导致Intra-LTE无法切换或切换失败的原因有哪些
1） 覆盖过差，eNB无法正确解调UE上报的测量报告；
2） 未配置测量控制信息；
3） UE测量配置中测量频点配置错误；
4） 邻区关系配置错误或漏配；
（以下为optional，可作为加分点）
5） 干扰；
6） T304配置过短；
7） 随机接入功率配置或信道配置不当；
8） 接纳控制失败
26 请简述上行物理信道的基带信号处理流程？
下行物理信道的基带信号处理，可以分为如下几步。
（1）对将在一个物理信道上传输的每个码字中的编码比特进行加扰。
（2）对加扰后的比特进行调制，产生复值符号。
（3）传输预编码，生成复值调制符号。
（4）将每一个天线端口上的复值调制符号映射到资源粒子上。
（5）为每一个天线端口产生复值的时域SC-FDMA信号。
27 某TDLTE R8处于小区B1超过20秒，邻区有A（高优先级）、B2（同优先级）及C（低优先级）。参数设置如下：hreshXHigh= threshXLow = threshServingLow=20dB；qOffsetCell=0dB；qHyst=6dB。tReselection=1;qRxLevMin=-115dBm；offsetFreq=0所有小区的RSRP测量值（连续一秒）如下：A： -97dBm B1：-96dBm B2：-92dBm C：-94dBm;请用R8的重选规则评估所有小区，然后找出最终重选目标小区
高优先级：A小区：Srxlev= -97-（-115）=18< threshXHigh(20)，不合格
同级别：B1小区：Rs =-96+6=-90 > B2小区：Rn=-92
低级别：
B1小区：Srxlev =-97-（-115）=19< threshServingLow (20)
C小区 Srxlev=-94-(-115)=21> threshXLow 满足
28 请写出TDLTE小区下行FSS调度的5个条件？
fdsOnly=False
吞吐量>=100kbps
多普勒频移<=463Hz
CQI>=minimumCQIForFSS
小区的FSS当前用户数<= maximumFSSUsers
29 TDLTE的PRACH采用格式0，循环周期为10ms，请问
1）子帧配比为配置1的基站的3扇区的prachConfigurationIndex分别是多少及对应的帧内子帧位置(从0开始)？2）子帧配比为配置2的基站的3扇区的prachConfigurationIndex分别是多少及对应的帧内子帧位置？(从0开始)
TDD配置1的3扇区的prachConfigurationIndex分别为3/4/5，分别对应3、8、2三个子帧
TDD配置2的3扇区的prachConfigurationIndex分别为3/4/4，分别对应2、7、7三个子帧
30 在LTE/EPC网络中的DNS服务器中使用哪几种记录类型？并且说明各中记录的解析结果。
A记录，用于解析出IPv4的地址；
AAAA记录，用于解析出IPv6的地址；
SRV（业务）记录，用于解析出具有权重和优先级的域名；
NAPTR（名称权威指针）记录，用于解析出具有权重和优先级，支持业务的NAPTR,SRV,或A,AAAA记录。
31 请画出OMC的物理架构和逻辑架构，并简要说明逻辑架构中各模块/单元的功能。
客户端：人机交互平台
应用服务器：负责各类事务处理和数据存储。包括：
（1）jboss：完成各类事务和数据处理。
（2）webstart：完成浏览器访问服务器的事务处理。
（3）数据库：完成各类数据的处理和存储。
（4）servermgr：监控服务器端运行和资源使用情况。
（5）NMA：完成与上级网管的协议和对象模型转换。
（6）license：完成OMC特性、接入数等的授权服务。
（7）DHCP：提供网管系统的IP自动分配等DHCP服务。
（8）NTP：保证OMC与所管网元的网管系统时钟同步。
（9）FTP：完成OMC与所管网元间的配置、告警、性能文件传递。
NEA：完成OMC系统内部与O接口之间的协议转换，及数据模型的转换；负责O接口链路的建立和维护。
pc：完成与网元性能数据上报相关的事务处理，如性能数据文件完整性校验、性能数据文件解析等。
MR服务器：完成MR、CDL等文件的存储和管理。
32 请简述OMC系统的告警级别及其影响。
1、严重告警：Critical（缩写为“C”），使业务中断并需要立即进行故障检修的告警。
2、主要告警：Major（缩写为“M”），影响业务并需要立即进行故障检修的告警。
3、次要告警：minor（缩写为“m”），不影响现有业务，但需检修以阻止恶化的告警。
4、警告告警：warning（缩写为“w”），不影响现有业务，但发展下去有可能影响业务，可视需要采取措施的告警。
5、清除告警：cleaned（缩写为“c”），指告警指示的故障已排除，系统恢复正常。消防物联网是什么？其中包含什么技术含义等，有谁能给个详细的解答
物联网消防技术 是指通过条码、射频识别、传感器等各种信息传感设备实时采集建筑物内所有消防设施的各种数据，同时与互联网结合形成一个巨大网络的综合技术。物联网消防技术目的实现消防系统与网络的连接，方便识别、管理和控制。
把网络技术运用于 万物，组成“物联网”如把 感应器 嵌入装备到油网、电网、路网、水网、建筑、大坝、等 物体中然后将“物联网”与“互联网”整合起来，实现 人类社会 与物理系统的整合超级计算机群 对“整合网”的人员、机器设备、基础设施 实施 实时管理控制以精细动态方式 管理生产生活,提高资源利用率和生产力水平,改善人与自然关系。
消防物联网技术是指射频识别、红外感应器、全球定位系统、激光扫描器等信息传感设备，按约定的协议推广使用消防物，将任何物品与互联网相连接，进行信息交换和通信，以实现智能化识别、定位、跟踪、监控和管理。消防人员可通过手持终端，快速准确获知需要救援的人员数量、位置及消防设施、设备的信息，为制定高效的救援方案提供科学数据参考，有助于整体调度，及时实施对被困人员的救助和充分发挥现场消防设施的效能，从而有效防止人员伤亡和财产损失。[1]
伴随着经常发展，为适应新形势下的消防安全技术，推动社会单位落实消防安全主体责任，江西赣州全面提升社会单位“四个能力”，将在全市近3000家消防安全重点单位全面推广使用物联网技术。[2]
当前，消防安全重点单位都已经投入使用了火灾自动报警系统等各类应急管理系统，并联入了各地的消防安全远程监控系统，这些系统在信息采集、传输、处理等方面与物联网技术有着相通之处，只要在其基础之上再构建一层基于物联网技术的系统，即可利用物联网技术有效拓展现有应急管理系统的功能。消防部队目前配备使用的灭火救援指挥系统、移动网络图像传输系统等都为物联网的应用提供了一定的平台。[1]
物联网消防技术为创新消防安全管理工作模式提供了有效途径。物联网简单说，就是“物物相连的互联网”。太原的物联网消防系统是如何“物物相连”的呢？记者了解到，整个系统大致分为感知层、网络层和应用层。感知层就是已经安装在建筑物中的火警感应设备、报警监控设备和自动灭火设备。应用层则是消防部门、防火重点部门。网络层则是通过有线或无线传输将感知层的险情隐患信息传递到应用层，并将应用层的消防指令传回感知层。[3]
针对消防物联网在信息传输上，能建立更有效、更便捷、更经济的数据传输模式；杜兰萍总工程师在山西督导消防物联网和平安消防专项行动，指出消防物联网的数据分析上，要针对不同类别、不同情况进行更深层次的研究分析，对联网单位的消防安全状况做到全面掌握；要充分利用此次课题研究的契机，以消防物联网技术为平台，创新消防安全管理机制；此项课题的技术研发和系统应用要充分运用原有基础和平台，包括地理信息开发、远程监控系统等；消防物联网运行机制要借鉴其他外省经验，要在 部门、网络运营商、维保单位、数据中心、联网单位和消防部门之间建立良好的互动机制和责任链条。杜兰萍总工希望课题组要继续努力，在先进的技术平台上探索出一种新的运行模式，通过试点运用将山西社会单位的消防安全管理水平再上一个新台阶。[4]
KYC的中文含义是了解你的客户，包含内容：国外的《反洗钱法》大多要求包括会计师事务所在内的自然人、法人和其他组织，要对自己的客户作出全面的了解，也就是了解你的客户原则。"了解你的客户"的主要目标是通过对客户身份的核实和商业行为的了解，有效地发现和报告可疑行为，因为除非对客户有充分的理解并能够预测客户的商业行为，否则你就无法合理而有效地从客户日常的、习惯性的行为中发现不正常的、或许是可疑的行为。通常这种了解，是通过对交易的受益方、来源和资金用途以及考虑企业经营历史后的企业行为和交易形式的恰当性和合理性作恰当的、尽职的调查，来获得完全的了解。
根据《金融行动工作组40条建议》的要求，了解客户原则的审查程序包括：
（1）确认直接客户的身份，也就是说知道该客户是什么人或什么主体；
（2）核实客户身份时，应使用可靠、独立的文件、数据或资料；
（3）确认实际所有权和控制权——确认是什么自然人最终拥有和控制直接客户，和/或交易的实际受益人；
（4）核实其客户的实际所有人和/或交易的实际受益人的身份；
（5）进行持续的尽职审查和详细审查——在与客户的商业关系存续期间对交易和账户进行持续的详细检查，以保证正在进行的交易与金融机构对客户、客户业务及客户风险状况的了解相一致，如果有必要的话，应确认资金的来源。
目前，了解你的客户原则被日益拓展到包括"了解你的雇员"、"了解你的代理人"和"了解你的关联方"，甚至"了解你的第三方服务提供商"上来，经验表明，通过欺瞒雇员和类似的当事人，将有助于实施和进行洗钱。
铸剑为犁
成语，谓销熔武器以制造田器。
也就是倡导和平，反对战争~~
语本《孔子家语·致思》：“铸剑习 以为农器，放牛马于原薮，室家无离旷之思，千岁无战斗之患。”
服装打版也叫服装纸样，是服装设计的一部分，大体上服装设计包括1、创作设计（款式图，包括款式、面料、色彩等等的表达）；2、结构设计（也叫打版，版型处理，每个部位的具体规格尺寸）；3、工艺设计（也叫车位，一件成品的缝制过程）。其中打版在中间是处于一个承上启下的作用，是整个服装设计里面最重要的一个环节。
服装纸样，也称为服装样板或服装模板，做服装纸样的过程叫出纸样，正确的名称应该是服装结构设计，服装结构设计是服装设计的重要组成部分，是服装厂的核心技术，它是联系创作设计和工艺设计的桥梁，是第二设计；结构设计师（厂里称纸样师傅）根据创作设计师的服装效果图和规格，或者根据客户的样板和规格，或者根据客户的制单，通过平面的或者立体的结构设计手法，按照符合人体的变化原理，先做出净样的底图，然后通过不同的方法（或者通过电脑打印，或者通过手工复印等）从底图上用硬纸板把样片剥离出来，再在样片上加上我们出纸样的九个方面（1缝份、2剪口、3布纹、4款号、5名称、6数量、7尺码、8粘合衬、9颜色），（详细资料可以参阅广东中山九元服装学校高鸿老师的专著：《服装结构设计及其应用》）最后通过检查没有问题，就可以交给车板工去车板了，这个过程就是出纸样的过程服装纸样是创作设计的延伸和实现，又是工艺设计的依据和基础，所以服装纸样在服装厂里占着举足轻重的位置，在厂里是绝对不可大意，切切。
物联网是新一代信息技术的重要组成部分，也是“信息化”时代的重要发展阶段。其英文名称是：“Inter of things（IoT）”。顾名思义，物联网就是物物相连的互联网。这有两层意思：其一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；其二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信，也就是物物相息。物联网通过智能感知、识别技术与普适计算等通信感知技术，广泛应用于网络的融合中，也因此被称为继计算机、互联网之后世界信息产业发展的第三次浪潮。物联网是互联网的应用拓展，与其说物联网是网络，不如说物联网是业务和应用。因此，应用创新是物联网发展的核心，以用户体验为核心的创新20是物联网发展的灵魂。
谁能给我解释一下物联网是什么东东啊？联网是新一代信息技术的重要组成部分。其英文名称是“The Inter of things”。由此，顾名思义，“物联网就是物物相连的互联网”。这有两层意思：第一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；第二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信。
蓝球盖冒技巧，有谁能给个详细的。和练习方法？ 快速d跳。
不是要多高，关键是出手瞬间就盖帽。
follow the world ····
IP互联网尖端技术是什么给个详细的介绍？互联网尖端技术发展很快的，可能我现在刚刚告诉你答案，马上又有新精尖的技术出来，你的问题太笼统，应有所指，划定某一范围。
谁能给个大棚礼品西瓜的栽培技术，详细的参考答案 28"他把他的整个生命的重量都压到了我的身上,我承受不了" 我悲伤的对顾里说
最近重新认知了一下TCP和UDP的原理以及区别，做一个简单的总结。
首先，tcp和udp都是工作在传输层，用于程序之间传输数据的。数据一般包含：文件类型，视频类型，jpg等。
TCP是基于连接的，而UDP是基于非连接的。
tcp传输数据稳定可靠 ，适用于对网络通讯质量要求较高的场景，需要准确无误的传输给对方，比如，传输文件，发送邮件，浏览网页等等
udp的优点是速度快 ，但是可能产生丢包，所以适用于对实时性要求较高但是对少量丢包并没有太大要求的场景。比如：域名查询，语音通话，视频直播等。udp还有一个非常重要的应用场景就是隧道网络，比如：VXLAN
以人与人之间的通信为例：UDP协议就相当于是写信给对方，寄出去信件之后不能知道对方是否收到信件，信件内容是否完整，也不能得到及时反馈，而TCP协议就像是打电话通信，在这一系列流程都能得到及时反馈，并能确保对方及时接收到。如下图：
tcp是如何保证以上过程的？
分为三个步骤： 三次握手，传输确认，四次挥手 。三次握手是建立连接的过程。
当客户端向服务端发起连接时，会先发一包连接请求数据，过去询问一下，能否与你建立连接？这包数据称之为SYN包，如果对端同意连接，则回复一包SYN+ACK包，客户端收到之后，发送一包ACK包，连接建立，因为这个过程中互相发送了三包数据，所以称之为三次握手。
这是为了防止，因为已失效的请求报文，突然又传到服务器，引起错误， 这是什么意思？
假设采用两次握手建立连接，客户端向服务端发送一个syn包请求建立连接，因为某些未知的原因，并没有到达服务器，在中间某个网络节点产生了滞留，为了建立连接，客户端会重发syn包，这次的数据包正常送达，服务端发送syn+ack之后就建立起了连接。
但是第一包数据阻塞的网络突然恢复，第一包syn包又送达到服务端，这时服务端会认为客户端又发起了一个新的连接，从而在两次握手之后进入等待数据状态，服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致，如果在三次握手的情况下，服务端收不到最后的ack包，自然不会认为连接建立成功。
所以三次握手本质上来说就是为了解决网络信道不可靠的问题，为了在不可靠的信道上建立起可靠的连接，经过三次握手之后，客户端和服务端都进入了数据传输状态。
一包数据可能会被拆成多包发送，如何处理丢包问题，这些数据包到达的先后顺序不同，如何处理乱序问题？
针对这些问题，tcp协议为每一个连接建立了发送缓冲区，从建立链接后的第一个字节的序列号为0，后面每个字节的序列号就会增加1，发送数据时，从数据缓冲区取一部分数据组成发送报文，在tcp协议头中会附带序列号和长度，接收端在收到数据后需要回复确认报文，确认报文中的ack等于接受序列号加长度，也就是下包数据发送的起始序列号，这样一问一答的发送方式，能够使发送端确认发送的数据已经被对方收到，发送端也可以发送一次的连续的多包数据，接受端只需要回复一次ack就可以了。如图：
六、四次挥手：
处于连接状态的客户端和服务端，都可以发起关闭连接请求，此时需要四次挥手来进行连接关闭。假设客户端主动发起连接关闭请求，他给服务端发起一包FIN包，标识要关闭连接，自己进入终止等待1装填，服务端收到FIN包，发送一包ACK包，标识自己进入了关闭等待状态，客户端进入终止等待2状态，这是 第二次挥手 ，服务端此时还可以发送未发送的数据，而客户端还可以接受数据，待服务端发送完数据之后，发送一包FIN包，最后进入确认状态，这是 第3次挥手 ，客户端收到之后恢复ACK包，进入超时等待状态，经过超时时间后关闭连接，而服务端收到ACK包后，立即关闭连接，这是 第四次挥手 。
为什么客户端要等待超时时间？这是为了保证对方已经收到ACK包，因为假设客户端发送完最后一包ACK包后释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在 最后确认状态，如果等待一段时间，这时服务端会因为没有收到ack包重发FIN包，客户端会响应 这个FIN包进行重发ack包，并刷新超时时间，这个机制跟第三次握手一样。也是为了保证在不可靠的网络链路中进行可靠的连接断开确认。
udp:首先udp协议是非连接的，发送数据就是把简单的数据包封装一下，然后从网卡发出去就可以了，数据包之间并没有状态上的联系，正因为udp这种简单的处理方式，导致他的性能损耗非常少，对于cpu，内存资源的占用也远小于tcp，但是对于网络传输过程中产生的丢包，udp并不能保证，所以udp在传输稳定性上要弱于tcp。
所以， tcp和udp的主要区别： tcp传输数据稳定可靠，适用于对网络通讯质量要求较高的场景，需要准确无误的传输给对方。比如，传输文件，发送邮件，浏览网页等等，udp的优点是速度快，但是可能产生丢包，所以适用于对实时性要求较高但是对少量丢包并没有太大要求的场景。比如：域名查询，语音通话，视频直播等。
udp还有一个非常重要的应用场景就是隧道网络，比如：VXLAN
TCP三次握手TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送)
FIN(finish结束) RST(reset重置) URG(urgent紧急)
Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机;
第二次握手：主机B收到请求后要确认联机信息，向A发送ack
number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack
number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
对于互联网业务来说，传统的直接访问数据库方式，主要通过数据分片、一主多从等方式来扛住读写流量，但随着数据量的积累和流量的激增，仅依赖数据库来承接所有流量，不仅成本高、效率低、而且还伴随着稳定性降低的风险。
鉴于大部分业务通常是读多写少（读取频率远远高于更新频率），甚至存在读 *** 作数量高出写 *** 作多个数量级的情况。因此， 在架构设计中，常采用增加缓存层来提高系统的响应能力 ，提升数据读写性能、减少数据库访问压力，从而提升业务的稳定性和访问体验。
根据 CAP 原理，分布式系统在可用性、一致性和分区容错性上无法兼得，通常由于分区容错无法避免，所以一致性和可用性难以同时成立。对于缓存系统来说， 如何保证其数据一致性是一个在应用缓存的同时不得不解决的问题 。
需要明确的是，缓存系统的数据一致性通常包括持久化层和缓存层的一致性、以及多级缓存之间的一致性，这里我们仅讨论前者。持久化层和缓存层的一致性问题也通常被称为双写一致性问题，“双写”意为数据既在数据库中保存一份，也在缓存中保存一份。
对于一致性来说，包含强一致性和弱一致性 ，强一致性保证写入后立即可以读取，弱一致性则不保证立即可以读取写入后的值，而是尽可能的保证在经过一定时间后可以读取到，在弱一致性中应用最为广泛的模型则是最终一致性模型，即保证在一定时间之后写入和读取达到一致的状态。对于应用缓存的大部分场景来说，追求的则是最终一致性，少部分对数据一致性要求极高的场景则会追求强一致性。
为了达到最终一致性，针对不同的场景，业界逐步形成了下面这几种应用缓存的策略。
— 1 —
Cache-Aside
Cache-Aside 意为旁路缓存模式，是应用最为广泛的一种缓存策略。下面的图示展示了它的读写流程，来看看它是如何保证最终一致性的。在读请求中，首先请求缓存，若缓存命中（cache hit），则直接返回缓存中的数据；若缓存未命中（cache miss），则查询数据库并将查询结果更新至缓存，然后返回查询出的数据（demand-filled look-aside ）。在写请求中，先更新数据库，再删除缓存（write-invalidate）。
1、为什么删除缓存，而不是更新缓存？
在 Cache-Aside 中，对于读请求的处理比较容易理解，但在写请求中，可能会有读者提出疑问，为什么要删除缓存，而不是更新缓存？站在符合直觉的角度来看，更新缓存是一个容易被理解的方案，但站在性能和安全的角度，更新缓存则可能会导致一些不好的后果。
首先是性能 ，当该缓存对应的结果需要消耗大量的计算过程才能得到时，比如需要访问多张数据库表并联合计算，那么在写 *** 作中更新缓存的动作将会是一笔不小的开销。同时，当写 *** 作较多时，可能也会存在刚更新的缓存还没有被读取到，又再次被更新的情况（这常被称为缓存扰动），显然，这样的更新是白白消耗机器性能的，会导致缓存利用率不高。
而等到读请求未命中缓存时再去更新，也符合懒加载的思路，需要时再进行计算。删除缓存的 *** 作不仅是幂等的，可以在发生异常时重试，而且写-删除和读-更新在语义上更加对称。
其次是安全 ，在并发场景下，在写请求中更新缓存可能会引发数据的不一致问题。参考下面的图示，若存在两个来自不同线程的写请求，首先来自线程 1 的写请求更新了数据库（step 1），接着来自线程 2 的写请求再次更新了数据库（step 3），但由于网络延迟等原因，线程 1 可能会晚于线程 2 更新缓存（step 4 晚于 step 3），那么这样便会导致最终写入数据库的结果是来自线程 2 的新值，写入缓存的结果是来自线程 1 的旧值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。
2、为什么先更新数据库，而不是先删除缓存？
另外，有读者也会对更新数据库和删除缓存的时序产生疑问，那么为什么不先删除缓存，再更新数据库呢？在单线程下，这种方案看似具有一定合理性，这种合理性体现在删除缓存成功。
但更新数据库失败的场景下，尽管缓存被删除了，下次读 *** 作时，仍能将正确的数据写回缓存，相对于 Cache-Aside 中更新数据库成功，删除缓存失败的场景来说，先删除缓存的方案似乎更合理一些。那么，先删除缓存有什么问题呢？
问题仍然出现在并发场景下，首先来自线程 1 的写请求删除了缓存（step 1），接着来自线程 2 的读请求由于缓存的删除导致缓存未命中，根据 Cache-Aside 模式，线程 2 继而查询数据库（step 2），但由于写请求通常慢于读请求，线程 1 更新数据库的 *** 作可能会晚于线程 2 查询数据库后更新缓存的 *** 作（step 4 晚于 step 3），那么这样便会导致最终写入缓存的结果是来自线程 2 中查询到的旧值，而写入数据库的结果是来自线程 1 的新值，即缓存落后于数据库，此时再有读请求命中缓存（ step 5 ），读取到的便是旧值。
另外，先删除缓存，由于缓存中数据缺失，加剧数据库的请求压力，可能会增大缓存穿透出现的概率。
3、如果选择先删除缓存，再更新数据库，那如何解决一致性问题呢？
为了避免“先删除缓存，再更新数据库”这一方案在读写并发时可能带来的缓存脏数据，业界又提出了延时双删的策略，即在更新数据库之后，延迟一段时间再次删除缓存，为了保证第二次删除缓存的时间点在读请求更新缓存之后，这个延迟时间的经验值通常应稍大于业务中读请求的耗时。
延迟的实现可以在代码中 sleep 或采用延迟队列。显而易见的是，无论这个值如何预估，都很难和读请求的完成时间点准确衔接，这也是延时双删被诟病的主要原因。
4、那么 Cache-Aside 存在数据不一致的可能吗？
在 Cache-Aside 中，也存在数据不一致的可能性。在下面的读写并发场景下，首先来自线程 1 的读请求在未命中缓存的情况下查询数据库（step 1），接着来自线程 2 的写请求更新数据库（step 2），但由于一些极端原因，线程 1 中读请求的更新缓存 *** 作晚于线程 2 中写请求的删除缓存的 *** 作（step 4 晚于 step 3），那么这样便会导致最终写入缓存中的是来自线程 1 的旧值，而写入数据库中的是来自线程 2 的新值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。
这种场景的出现，不仅需要缓存失效且读写并发执行，而且还需要读请求查询数据库的执行早于写请求更新数据库，同时读请求的执行完成晚于写请求。足以见得，这种 不一致场景产生的条件非常严格，在实际的生产中出现的可能性较小 。
除此之外，在并发环境下，Cache-Aside 中也存在读请求命中缓存的时间点在写请求更新数据库之后，删除缓存之前，这样也会导致读请求查询到的缓存落后于数据库的情况。
虽然在下一次读请求中，缓存会被更新，但如果业务层面对这种情况的容忍度较低，那么可以采用加锁在写请求中保证“更新数据库&删除缓存”的串行执行为原子性 *** 作（同理也可对读请求中缓存的更新加锁）。 加锁势必会导致吞吐量的下降，故采取加锁的方案应该对性能的损耗有所预期。
— 2 —
补偿机制
我们在上面提到了，在 Cache-Aside 中可能存在更新数据库成功，但删除缓存失败的场景，如果发生这种情况，那么便会导致缓存中的数据落后于数据库，产生数据的不一致的问题。
其实，不仅 Cache-Aside 存在这样的问题，在延时双删等策略中也存在这样的问题。针对可能出现的删除失败问题，目前业界主要有以下几种补偿机制。
1、删除重试机制
由于同步重试删除在性能上会影响吞吐量，所以常通过引入消息队列，将删除失败的缓存对应的 key 放入消息队列中，在对应的消费者中获取删除失败的 key ，异步重试删除。这种方法在实现上相对简单，但由于删除失败后的逻辑需要基于业务代码的 trigger 来触发 ，对业务代码具有一定入侵性。
鉴于上述方案对业务代码具有一定入侵性，所以需要一种更加优雅的解决方案，让缓存删除失败的补偿机制运行在背后，尽量少的耦合于业务代码。一个简单的思路是通过后台任务使用更新时间戳或者版本作为对比获取数据库的增量数据更新至缓存中，这种方式在小规模数据的场景可以起到一定作用，但其扩展性、稳定性都有所欠缺。
一个相对成熟的方案是基于 MySQL 数据库增量日志进行解析和消费，这里较为流行的是阿里巴巴开源的作为 MySQL binlog 增量获取和解析的组件 canal（类似的开源组件还有 Maxwell、Databus 等）。
canal sever 模拟 MySQL slave 的交互协议，伪装为 MySQL slave，向 MySQL master 发送 dump 协议，MySQL master 收到 dump 请求，开始推送 binary log 给 slave （即 canal sever ），canal sever 解析 binary log 对象（原始为 byte 流），可由 canal client 拉取进行消费，同时 canal server 也默认支持将变更记录投递到 MQ 系统中，主动推送给其他系统进行消费。
在 ack 机制的加持下，不管是推送还是拉取，都可以有效的保证数据按照预期被消费。当前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依赖 ZooKeeper 作为分布式协调组件来实现 HA ，canal 的 HA 分为两个部分：
那么，针对缓存的删除 *** 作便可以在 canal client 或 consumer 中编写相关业务代码来完成。这样，结合数据库日志增量解析消费的方案以及 Cache-Aside 模型，在读请求中未命中缓存时更新缓存（通常这里会涉及到复杂的业务逻辑），在写请求更新数据库后删除缓存，并基于日志增量解析来补偿数据库更新时可能的缓存删除失败问题，在绝大多数场景下，可以有效的保证缓存的最终一致性。
另外需要注意的是，还应该隔离事务与缓存，确保数据库入库后再进行缓存的删除 *** 作。 比如考虑到数据库的主从架构，主从同步及读从写主的场景下，可能会造成读取到从库的旧数据后便更新了缓存，导致缓存落后于数据库的问题，这就要求对缓存的删除应该确保在数据库 *** 作完成之后。所以，基于 binlog 增量日志进行数据同步的方案，可以通过选择解析从节点的 binlog，来避免主从同步下删除缓存过早的问题。
3、数据传输服务 DTS
— 3 —
Read-Through
Read-Through 意为读穿透模式，它的流程和 Cache-Aside 类似，不同点在于 Read-Through 中多了一个访问控制层，读请求只和该访问控制层进行交互，而背后缓存命中与否的逻辑则由访问控制层与数据源进行交互，业务层的实现会更加简洁，并且对于缓存层及持久化层交互的封装程度更高，更易于移植。
— 4 —
Write-Through
Write-Through 意为直写模式，对于 Write-Through 直写模式来说，它也增加了访问控制层来提供更高程度的封装。不同于 Cache-Aside 的是，Write-Through 直写模式在写请求更新数据库之后，并不会删除缓存，而是更新缓存。
这种方式的 优势在于读请求过程简单 ，不需要查询数据库更新缓存等 *** 作。但其劣势也非常明显，除了上面我们提到的更新数据库再更新缓存的弊端之外，这种方案还会造成更新效率低，并且两个写 *** 作任何一次写失败都会造成数据不一致。
如果要使用这种方案， 最好可以将这两个 *** 作作为事务处理，可以同时失败或者同时成功，支持回滚，并且防止并发环境下的不一致 。另外，为了防止缓存扰动的频发，也可以给缓存增加 TTL 来缓解。
站在可行性的角度，不管是 Write-Through 模式还是 Cache-Aside 模式，理想状况下都可以通过分布式事务保证缓存层数据与持久化层数据的一致性，但在实际项目中，大多都对一致性的要求存在一些宽容度，所以在方案上往往有所折衷。
Write-Through 直写模式适合写 *** 作较多，并且对一致性要求较高的场景，在应用 Write-Through 模式时，也需要通过一定的补偿机制来解决它的问题。首先，在并发环境下，我们前面提到了先更新数据库，再更新缓存会导致缓存和数据库的不一致，那么先更新缓存，再更新数据库呢？
这样的 *** 作时序仍然会导致下面这样线程 1 先更新缓存，最后更新数据库的情况，即由于线程 1 和 线程 2 的执行不确定性导致数据库和缓存的不一致。这种由于线程竞争导致的缓存不一致，可以通过分布式锁解决，保证对缓存和数据库的 *** 作仅能由同一个线程完成。对于没有拿到锁的线程，一是通过锁的 timeout 时间进行控制，二是将请求暂存在消息队列中顺序消费。
在下面这种并发执行场景下，来自线程 1 的写请求更新了数据库，接着来自线程 2 的读请求命中缓存，接着线程 1 才更新缓存，这样便会导致线程 2 读取到的缓存落后于数据库。同理，先更新缓存后更新数据库在写请求和读请求并发时，也会出现类似的问题。面对这种场景，我们也可以加锁解决。
另在，在 Write-Through 模式下，不管是先更新缓存还是先更新数据库，都存在更新缓存或者更新数据库失败的情况，上面提到的重试机制和补偿机制在这里也是奏效的。
— 5 —
Write-Behind
Write behind 意为异步回写模式，它也具有类似 Read-Through/Write-Through 的访问控制层，不同的是，Write behind 在处理写请求时，只更新缓存而不更新数据库，对于数据库的更新，则是通过批量异步更新的方式进行的，批量写入的时间点可以选在数据库负载较低的时间进行。
在 Write-Behind 模式下，写请求延迟较低，减轻了数据库的压力，具有较好的吞吐性。但数据库和缓存的一致性较弱，比如当更新的数据还未被写入数据库时，直接从数据库中查询数据是落后于缓存的。同时，缓存的负载较大，如果缓存宕机会导致数据丢失，所以需要做好缓存的高可用。显然，Write behind 模式下适合大量写 *** 作的场景，常用于电商秒杀场景中库存的扣减。
— 6 —
Write-Around
如果一些非核心业务，对一致性的要求较弱，可以选择在 cache aside 读模式下增加一个缓存过期时间，在写请求中仅仅更新数据库，不做任何删除或更新缓存的 *** 作，这样，缓存仅能通过过期时间失效。这种方案实现简单，但缓存中的数据和数据库数据一致性较差，往往会造成用户的体验较差，应慎重选择。
— 7 —
总结
在解决缓存一致性的过程中，有多种途径可以保证缓存的最终一致性，应该根据场景来设计合适的方案，读多写少的场景下，可以选择采用“Cache-Aside 结合消费数据库日志做补偿”的方案，写多的场景下，可以选择采用“Write-Through 结合分布式锁”的方案 ，写多的极端场景下，可以选择采用“Write-Behind”的方案。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）