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
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协议传输较为合适。
1700508950
1700508952
12.2.3 加密问题
1700508953
1700508954
当终端或者服务器本地拿到数据要进行传输的时候，要注意数据加密的问题——是否担心传输的数据在网络上被人监听，然后被人恶意复制或篡改？
1700508955
1700508956
以太网的基本协议是CSMA/CD（Carrier Sense Multiple Access with Collision Detection，带冲突检测的载波监听多路访问技术），也就是说，在一个子网中，一块无线网卡(7)在混杂模式下可以听到其他网卡传输的信息，这是极不安全的。在传输过程中，如果信息较为重要，一旦被他人监听，也有信息泄露的风险。所以，这种情况下通常采用加密传输的方式。
1700508957
1700508958
如果终端或服务器支持HTTPS协议栈，可以考虑直接使用HTTPS协议进行传输，代价就是每次传输连接建立的时候会花费更长的时间。如果终端或服务器使用FTP和SSL的文件传输方式，也相对比较安全。现在常用的SSL证书有128位、256位、512位、1024位、2048位（现在银行大多使用2048位的证书）等，位数越长，破解越困难，而且破解时间以指数级别增长。
1700508959
1700508960
在单片机和DTU的数据收集环境中，由于硬件资源所限，基本没有支持HTTPS协议的情况。如果要加密，需要自行编写（通常用C语言）加/解密算法。
1700508961
1700508962
这种加/解密按大类通常可分为对称加密和非对称加密。比较成熟的对称加密算法有DES、3DES、TDEA、Blowfish、RC5、IDEA等；比较成熟的非对称加密算法有RSA、ElGamal等。从安全性上来说，非对称算法要比对称算法更为安全。
1700508963
1700508964
1．对称加密
1700508965
[
上一页 ]
[ :1.700508916e+09 ]
[
下一页 ]