1700508900
1700508901
策略1：日志最安全
1700508902
1700508903
日志安全的概念就是绝对不允许发生日志的丢失。只要日志在本地主机提交成功，就一定要保证日志在远程主机也提交成功，才算这条日志提交成功。而在确认这条日志在远程主机提交成功之前，本地主机必须处于“停等”的状态。这种方式看上去确实安全，能够保证本机和远程主机的日志高度一致，但是效率非常低。
1700508904
1700508905
策略2：效率最高
1700508906
1700508907
效率最高的概念就是：只要日志在本地提交成功，就算提交成功，至于远程主机提交是否成功则根本不予理会。Fluentd其实就是这种工作状态，它也只能在这种工作状态下工作。因为无论如何，这种将日志传递到远程的工作在Fluentd应用场景中是一个“增值服务”，不是本地主机业务方的业务目的，为了这个不太重要的目的牺牲大量的时间做“停等”是一种本末倒置的行为。
1700508908
1700508909
Oracle数据库在8i(6)版本之后提供了一个叫作“Dataguard”的功能（如图12-5所示），其设计目的是实现高可用，尤其是像Oracle这种对实时性和事务都很重视的数据库产品更是如此。Dataguard的工作原理是：用1台主数据库服务器Primary来接受正常的事务请求，再准备1台或多台Standby数据库服务器提供备用功能。在Primary上提交的Redo日志都会通过网络复制到Standby上，然后复用到Standby数据库中，从而使Primary数据库和Standby数据库中的数据保持一致。这样，一旦Primary数据库发生崩溃，可以立刻将对外服务数据库切换为Standby数据库。
1700508910
1700508911
1700508912
1700508913
1700508914
图12-5 OracIe Dataguard工作原理示意图
1700508915
1700508916
Dataguard提供如下3种保护模式。
1700508917
1700508918
（1）最大保护
1700508919
1700508920
最大保护是指除非Redo日志在至少一个Standby上可用，否则事务不能提交。如果在某个Standby上不可用，则Primary数据库的操作会被停止。最大保护受到的制约比较多，在生产环境中并不常用——这就是前面说的“日志最安全”策略。
1700508921
1700508922
（2）最大可用
1700508923
1700508924
最大可用是指如果Standby数据库不可用，Primary数据库仍然可以处理事务，只是在Standby数据库恢复后，Standby和Primary数据库进行再同步。这样就导致了一个问题：在Standby数据库发生故障后到恢复前，如果Primary数据库也发生故障，就无法实现高可用了。如果强行设置Standby数据库为Primary数据库，有些数据可能会丢失。
1700508925
1700508926
（3）最大性能
1700508927
1700508928
最大性能是指Primary数据库的提交操作不等待Standby数据库。Primary和Standby松耦合，数据保护级别较低——这就是前面说的“效率最高”策略。
1700508929
1700508930
所以，安全和效率这对矛盾的决策问题都会让人很苦恼。我们在实际生产环境中，只能在日志数据由于无法传递而产生的损失和为了避免这种损失而采取的技术方案所产生的费用之间做取舍。显然，不论选择哪一种，如果花费比损失小，这个方案就是一个基本划算的方案。
1700508931
1700508932
矛盾就是这样，没法两全其美，而一般情况下，通常也只能是牺牲实时性来保证数据完整性，或者牺牲数据完整性来保证实时性。只要选择的是后者，问题就来了——数据有一定的丢失概率，而我们可能要用丢失的数据来做后续的各种工作。这，只是不靠谱的开始。在这种情况下，我们能做的就是估算丢失数据的量（如果有必要）。估算方法有很多：一种方法是强行在主机上生成连续的日志编号（从0一直到264），然后在服务器主机上统计一个时间段内收到日志的条目数与编号的最大/最小值的差值之商；还有一种方法，就是直接统计一个时间段内主机和服务器各自收到的日志条目数——都是用估算丢失量的方法来补充，对已收到的数据进行纠偏。
1700508933
1700508934
对于不太重要的日志，刚刚这些补救措施可以都不做，只要相信互联网和服务器的可靠性已经能够满足当前日志收集业务的需求就可以了——好在现在互联网业务的绝大多数场景都是这样。
1700508935
1700508936
数据科学家养成手册 [:1700503607]
1700508937
12.2.2 延时上传
1700508938
1700508939
一些在终端使用DTU上传的场景中，终端通常没有存储数据的能力，所以这种情况通常不允许延时上传。这样，延时上传实际上只有如下两种场景了。
1700508940
1700508941
方式1：在终端使用Wi-Fi或有线以太网上传
1700508942
1700508943
这种方式还是刚刚说的在类似智能手机或者PC使用的场景中上传。在这种情况下，设备的内存大都可以暂存数据，例如将收集到的数据积累1分钟或更久再上传，而不是随着扫描立刻上传。这种方式的好处主要是，使用短连接与服务器进行通信，可以减少开合服务器连接的次数，进而减少服务器端不必要的并发开销。
1700508944
1700508945
此外，这种方式还可以做一个增强，就是在网络失效的情况下积累更长时间的数据，直到网络恢复的时候再报送——让数据在本地“攒”一会儿。这种方式会在一定程度上降低由网络失效带来的数据报送损失，代价是本地终端要付出一定的空间。务必注意使用这种方案时的内存管理策略，不要影响正常软件功能的使用。
1700508946
1700508947
方式2：在服务器端使用以太网上传
1700508948
1700508949
这种方式也是应用比较普遍的，尤其是在对实时性要求不强的场景中。在这种情况下，日志数据会以小时或者天为单位向指定的日志收集服务器上传。由于这种情况通常以文件作为传输单位，所以使用HTTP协议或者FTP协议传输较为合适。