精华内容
下载资源
问答
  • sleuth+zipkin 调用追踪全量日志方案 spring cloud中的zipkin日志统计是由sleuth客户端和zipkin服务器组成。sleuth收集客端trace,通过mq将trace发送到zipkin服务器。 zipkin 做持久化和查询展示功能...

    spring cloud中的zipkin日志统计是由sleuth客户端和zipkin服务器组成。 sleuth收集客端trace,通过mq将trace发送到zipkin服务器。

    zipkin 做持久化和查询展示功能。常用kafka+zk集群作为mq将信息由客户端发往服务器,elasticsearch用于trace存储。

    存在以下问题:

    1.大量trace发往zipkin很容易崩溃,通常不能做全量记录。

    2.如果zipkin崩溃或者mq出现问题会导致trace丢失。

    解决:

    a.不引入mq依赖,使用日志记录调用信息。

        @Bean
        public Reporter<Span> reporter(){
            return span ->  { logger.info(span.toString()); }; //输出到trace日志文件
        }
    
        @Bean
        public Sampler sleuthTraceSampler() {
            return Sampler.ALWAYS_SAMPLE;
        } //全量记录

     

    b.使用elk日志方案将日志导入到trace专用索引。

    c.zipkin对数据包括收集和查询展示两模块。我正常配置zipkin+es,就ok了。只是没有不使用收集模块。

     

    posted on 2018-12-16 23:52 NullToValue 阅读(...) 评论(...) 编辑 收藏

    转载于:https://www.cnblogs.com/nullAndValue/p/10129224.html

    展开全文
  • Redis主从复制原理总结 和Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从...- 从服务器连接主服务器,发送SYNC命令; - 主服务器接...

    Redis主从复制原理总结

    和Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。 

    全量同步


    Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下: 
    -  从服务器连接主服务器,发送SYNC命令; 
    -  主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令; 
    -  主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令; 
    -  从服务器收到快照文件后丢弃所有旧数据,载入收到的快照; 
    -  主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令; 
    -  从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;

    完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。

    增量同步


    Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
    增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
     
     

    Redis主从同步策略


    主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
     
    注意点
    如果多个Slave断线了,需要重启的时候,因为只要Slave启动,就会发送sync请求和主机全量同步,当多个同时出现的时候,可能会导致Master IO剧增宕机。

    Redis主从复制的配置十分简单,它可以使从服务器是主服务器的完全拷贝。需要清除Redis主从复制的几点重要内容:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    1)Redis使用异步复制。但从Redis 2.8开始,从服务器会周期性的应答从复制流中处理的数据量。

    2)一个主服务器可以有多个从服务器。

    3)从服务器也可以接受其他从服务器的连接。除了多个从服务器连接到一个主服务器之外,多个从服务器也可以连接到一个从服务器上,形成一个

       图状结构。

    4)Redis主从复制不阻塞主服务器端。也就是说当若干个从服务器在进行初始同步时,主服务器仍然可以处理请求。

    5)主从复制也不阻塞从服务器端。当从服务器进行初始同步时,它使用旧版本的数据来应对查询请求,假设你在redis.conf配置文件是这么配置的。

       否则的话,你可以配置当复制流关闭时让从服务器给客户端返回一个错误。但是,当初始同步完成后,需要删除旧的数据集和加载新的数据集,在

       这个短暂的时间内,从服务器会阻塞连接进来的请求。

    6)主从复制可以用来增强扩展性,使用多个从服务器来处理只读的请求(比如,繁重的排序操作可以放到从服务器去做),也可以简单的用来做数据冗余。

    7)使用主从复制可以为主服务器免除把数据写入磁盘的消耗:在主服务器的redis.conf文件中配置“避免保存”(注释掉所有“保存“命令),然后连接一个配

       置为“进行保存”的从服务器即可。但是这个配置要确保主服务器不会自动重启(要获得更多信息请阅读下一段)

    主从复制的一些特点:

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    1)采用异步复制;

    2)一个主redis可以含有多个从redis;

    3)每个从redis可以接收来自其他从redis服务器的连接;

    4)主从复制对于主redis服务器来说是非阻塞的,这意味着当从服务器在进行主从复制同步过程中,主redis仍然可以处理外界的访问请求;

    5)主从复制对于从redis服务器来说也是非阻塞的,这意味着,即使从redis在进行主从复制过程中也可以接受外界的查询请求,只不过这时候从redis返回的是以前老的数据,

       如果你不想这样,那么在启动redis时,可以在配置文件中进行设置,那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端;(虽然说主从复制过程中

       对于从redis是非阻塞的,但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中,在加载到内存的过程中是阻塞的,在这段时间内的请求将会被阻,

       但是即使对于大数据集,加载到内存的时间也是比较多的);

    6)主从复制提高了redis服务的扩展性,避免单个redis服务器的读写访问压力过大的问题,同时也可以给为数据备份及冗余提供一种解决方案;

    7)为了编码主redis服务器写磁盘压力带来的开销,可以配置让主redis不在将数据持久化到磁盘,而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘,

       不过这样会存在一个问题,就是主redis服务器一旦重启,因为主redis服务器数据为空,这时候通过主从同步可能导致从redis服务器上的数据也被清空;

    Redis大概主从同步是怎么实现的?

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    全量同步:

    master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件,与此同时,服务器会缓存所有接收到的来自客户端的写命令(包含增、删、改),当后台保存进程

    处理完毕后,会将该rdb文件传递给slave服务器,而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存,在此之后master服务器会将在此期间缓存的

    命令通过redis传输协议发送给slave服务器,然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

     

    部分同步:

    从redis 2.8版本以前,并不支持部分同步,当主从服务器之间的连接断掉之后,master服务器和slave服务器之间都是进行全量数据同步,但是从redis 2.8开

    始,即使主从连接中途断掉,也不需要进行全量同步,因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了

    一份同步日志和同步标识,每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后,slave服务器隔断时间

    (默认1s)主动尝试和master服务器进行连接,如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中,那么就从slave发送的偏移量开始继续上次的同步

    操作,如果slave发送的偏移量已经不再master的同步备份日志中(可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作),则

    必须进行一次全量更新。在部分同步过程中,master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

    主从同步中需要注意几个问题

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    1)在上面的全量同步过程中,master会将数据保存在rdb文件中然后发送给slave服务器,但是如果master上的磁盘空间有效怎么办呢?那么此时全部同步对于master来说

    将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的,由master直接开启一个socket将rdb文件发送给slave服务器。(无盘复制一般应用在磁盘空间有限但是网

    络状态良好的情况下)

     

    2)主从复制结构,一般slave服务器不能进行写操作,但是这不是死的,之所以这样是为了更容易的保证主和各个从之间数据的一致性,如果slave服务器上数据进行了修改,

    那么要保证所有主从服务器都能一致,可能在结构上和处理逻辑上更为负责。不过你也可以通过配置文件让从服务器支持写操作。(不过所带来的影响还得自己承担哦。。。)

     

    3)主从服务器之间会定期进行通话,但是如果master上设置了密码,那么如果不给slave设置密码就会导致slave不能跟master进行任何操作,所以如果你的master服务器

    上有密码,那么也给slave相应的设置一下密码吧(通过设置配置文件中的masterauth);

     

    4)关于slave服务器上过期键的处理,由master服务器负责键的过期删除处理,然后将相关删除命令已数据同步的方式同步给slave服务器,slave服务器根据删除命令删除

    本地的key。

    当主服务器不进行持久化时复制的安全性

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    在进行主从复制设置时,强烈建议在主服务器上开启持久化,当不能这么做时,比如考虑到延迟的问题,应该将实例配置为避免自动重启。

     

    为什么不持久化的主服务器自动重启非常危险呢?

    为了更好的理解这个问题,看下面这个失败的例子,其中主服务器和从服务器中数据库都被删除了。

     

    设置节点A为主服务器,关闭持久化,节点B和C从节点A复制数据。

    这时出现了一个崩溃,但Redis具有自动重启系统,重启了进程,因为关闭了持久化,节点重启后只有一个空的数据集。

    节点B和C从节点A进行复制,现在节点A是空的,所以节点B和C上的复制数据也会被删除。

    当在高可用系统中使用Redis Sentinel,关闭了主服务器的持久化,并且允许自动重启,这种情况是很危险的。

    比如主服务器可能在很短的时间就完成了重启,以至于Sentinel都无法检测到这次失败,那么上面说的这种失败的情况就发生了。

     

    如果数据比较重要,并且在使用主从复制时关闭了主服务器持久化功能的场景中,都应该禁止实例自动重启。

    Redis主从复制是如何工作的

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    如果设置了一个从服务器,在连接时它发送了一个SYNC命令,不管它是第一次连接还是再次连接都没有关系。

     

    然后主服务器开始后台存储,并且开始缓存新连接进来的修改数据的命令。当后台存储完成后,主服务器把数据文件发送到从服务器,

    从服务器将其保存在磁盘上,然后加载到内存中。然后主服务器把刚才缓存的命令发送到从服务器。这是作为命令流来完成的,并且

    和Redis协议本身格式相同。

     

    你可以通过telnet自己尝试一下。在Redis服务器工作时连接到Redis端口,发送SYNC命令,会看到一个批量的传输,并且主服务器接收

    的每一个命令都会通过telnet会话重新发送一遍。

     

    当主从服务器之间的连接由于某些原因断开时,从服务器可以自动进行重连接。当有多个从服务器同时请求同步时,主服务器只进行一个后台存储。

     

    当连接断开又重新连上之后,一般都会进行一个完整的重新同步,但是从Redis2.8开始,只重新同步一部分也可以。

    部分重新同步

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    从Redis 2.8开始,如果遭遇连接断开,重新连接之后可以从中断处继续进行复制,而不必重新同步。

     

    它的工作原理是这样:

    主服务器端为复制流维护一个内存缓冲区(in-memory backlog)。主从服务器都维护一个复制偏移量(replication offset)和master run id 

    当连接断开时,从服务器会重新连接上主服务器,然后请求继续复制,假如主从服务器的两个master run id相同,并且指定的偏移量在内存缓冲

    区中还有效,复制就会从上次中断的点开始继续。如果其中一个条件不满足,就会进行完全重新同步(在2.8版本之前就是直接进行完全重新同步)。

    因为主运行id不保存在磁盘中,如果从服务器重启了的话就只能进行完全同步了。

     

    部分重新同步这个新特性内部使用PSYNC命令,旧的实现中使用SYNC命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令,不支持的

    话使用SYNC命令。

    无磁盘复制

    1

    2

    3

    4

    通常来讲,一个完全重新同步需要在磁盘上创建一个RDB文件,然后加载这个文件以便为从服务器发送数据。

     

    如果使用比较低速的磁盘,这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。

    使用这种设置时,子进程直接将RDB通过网络发送给从服务器,不使用磁盘作为中间存储。

    配置

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    主从复制的配置十分简单:把下面这行加入到从服务器的配置文件中即可。

    slaveof 192.168.1.1 6379

     

    当然你需要把其中的192.168.1.1 6379替换为你自己的主服务器IP(或者主机名hostname)和端口。另外你可以调用SLAVEOF命令,

    主服务器就会开始与从服务器同步。

     

    关于部分重新同步,还有一些针对复制内存缓冲区的优化参数。查看Redis介质中的Redis.conf示例获得更多信息。

     

    使用repl-diskless-sync配置参数来启动无磁盘复制。使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间,以便等待

    更多的从服务器连接上来。查看Redis介质中的Redis.conf示例获得更多信息。

    只读从服务器

    1

    2

    3

    4

    5

    6

    7

    8

    从Redis 2.6开始,从服务器支持只读模式,并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的,

    可以在运行中通过CONFIG SET来启用或者禁用。

     

    只读的从服务器会拒绝所有写命令,所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下,

    因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。

     

    你可能想知道为什么只读限制还可以被还原,使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后,

    这些写操作都会失效,还是有一些使用场景会想从服务器中写入临时数据的,但将来这个特性可能会被去掉。

    限制有N个以上从服务器才允许写入

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    从Redis 2.8版本开始,可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。但是,因为Redis使用的是异步主从复制,

    没办法确保从服务器确实收到了要写入的数据,所以还是有一定的数据丢失的可能性。

     

    这一特性的工作原理如下:

    1)从服务器每秒钟ping一次主服务器,确认处理的复制流数量。

    2)主服务器记住每个从服务器最近一次ping的时间。

    3)用户可以配置最少要有N个服务器有小于M秒的确认延迟。

    4)如果有N个以上从服务器,并且确认延迟小于M秒,主服务器接受写操作。

     

    还可以把这看做是CAP原则(一致性,可用性,分区容错性)不严格的一致性实现,虽然不能百分百确保一致性,但至少保证了丢失的数据不会超过M秒内的数据量。

     

    如果条件不满足,主服务器会拒绝写操作并返回一个错误。

    1)min-slaves-to-write(最小从服务器数)

    2)min-slaves-max-lag(从服务器最大确认延迟)

    Redis 持久化日志

    RDB 是主进程 fork一个子进程进行的、所以不影响主进程的操作。

    AOF 和主进程是一个线程(redis是单线程)会对主进程对外提供请求的效率造成影响,接收请求、处理请求、写aof文件这三步是串行原子执行的。而非异步多线程执行的。

    ======            通过redis实现服务器崩溃等数据恢复             ======
    由于redis存储在内存中且提供一般编程语言常用的数据结构存储类型,所以经常被用于做服务器崩溃宕机的数据恢复处理。服务器可以在某些指定过程中将需要保存的数据以json对象等方式存储到redis中,也就是我们常说的快照,当服务器运行时读取redis来判断是否有待需要恢复数据继续处理的业务。当一次业务处理结束后再删除redis的数据即可。redis提供两种将内存数据导出到硬盘实现数据备份的方法

    1)RDB方式(默认)


    RDB方式的持久化是通过快照(snapshotting)完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义,由两个参数构成:时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是redis默认采用的持久化方式,在配置文件中已经预置了3个条件:
    save 900 1      #900秒内有至少1个键被更改则进行快照
    save 300 10     #300秒内有至少10个键被更改则进行快照
    save 60 10000   #60秒内有至少10000个键被更改则进行快照

     

    可以存在多个条件,条件之间是"或"的关系,只要满足其中一个条件,就会进行快照。 如果想要禁用自动快照,只需要将所有的save参数删除即可。
    Redis默认会将快照文件存储在当前目录(可CONFIG GET dir来查看)的dump.rdb文件中,可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

     

    Redis实现快照的过程


    -  Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
    -  父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;
    -  当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。
    -  在执行fork的时候操作系统(类Unix操作系统)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令 ),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。

     

    Redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。

     

    除了自动快照,还可以手动发送SAVE或BGSAVE命令让Redis执行快照,两个命令的区别在于,前者是由主进程进行快照操作,会阻塞住其他请求,后者会通过fork子进程进行快照操作。 Redis启动后会读取RDB快照文件,将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同,这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20~30秒钟。 通过RDB方式实现持久化,一旦Redis异常退出,就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合,通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失,则可以考虑使用AOF方式进行持久化。

    日志格式

    是压缩过的占用体积小,容灾恢复快
    $cat dump.rdb
    REDIS0008    redis-ver4.0.1
    redis-bits@ctimeYused-mem 
                                    aof-preamblerepl-id(484f9d49a700c4b9b136f0fd40d2d6e5a8460438
                                                                                                   repl-offa;^foobarfoobar^KJ_U

    OMG...一堆乱码隐约可以看到一些和redis相关的字符串为了更直观的感受下RDB的内容我们用redis自带的工具redis-check-rdb来看下

    
     
    redis-check-rdb dump.rdb
    [offset 0] Checking RDB file dump.rdb
    [offset 26] AUX FIELD redis-ver = '4.0.1'
    [offset 40] AUX FIELD redis-bits = '64'
    [offset 52] AUX FIELD ctime = '1504234774'
    [offset 67] AUX FIELD used-mem = '2139016'
    [offset 83] AUX FIELD aof-preamble = '0'
    [offset 133] AUX FIELD repl-id = '484f9d49a700c4b9b136f0fd40d2d6e5a8460438'
    [offset 148] AUX FIELD repl-offset = '0'
    [offset 150] Selecting DB ID 0
    [offset 173] Selecting DB ID 2
    [offset 194] Checksum OK
    [offset 194] \o/ RDB looks OK! \o/
    [info] 2 keys read
    [info] 1 expires
    [info] 0 already expired

    这下就好看多了首先可以看到是一些AUX FIELD辅助域4.0特有用来配合全新的主从同步方式PSYNC2后面会专门来介绍PSYNC2然后可以看到DB0和DB2是有内容的Checksum也OK最后是说一共有2个key其中一个设置了过期时间到目前为止还都没有过期。

    2)AOF方式


    默认情况下Redis没有开启AOF(append only file)方式的持久化,可以在redis.conf中通过appendonly参数开启:

    appendonly yes
    在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,载入的速度相较RDB会慢一些

    开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改:

    appendfilename appendonly.aof
    配置redis自动重写AOF文件的条件

    auto-aof-rewrite-percentage 100  # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据

    auto-aof-rewrite-min-size 64mb   # 允许重写的最小AOF文件大小
    配置写入AOF文件后,要求系统刷新硬盘缓存的机制

    # appendfsync always   # 每次执行写入都会执行同步,最安全也最慢
    appendfsync everysec   # 每秒执行一次同步操作
    # appendfsync no       # 不主动进行同步操作,而是完全交由操作系统来做(即每30秒一次),最快也最不安全

    Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少

    日志格式

    没有压缩的,文件大,容灾恢复慢

    同样的数据我们来看下在AOF文件中是如何保存的
    
    $cat appendonly.aof
    *2
    $6
    SELECT
    $1
    0
    *3
    $3
    set
    $3
    foo
    $3
    bar
    *3
    $9
    PEXPIREAT
    $3
    foo
    $13
    1504255377087
    *2
    $6
    

     很明显一条一条的没有压缩的命令

    3)混合RDF/AOF 方式

    在redis4.0 可以开启会和模式,默认时关闭的

    混合持久化同样也是通过bgrewriteaof完成的,不同的是当开启混合持久化时,fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据,如下图:

     

    数据恢复

    当我们开启了混合持久化时,启动redis依然优先加载aof文件,aof文件加载可能有两种情况如下:

    aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。

    aof文件开头不是rdb的格式,直接以aof格式加载整个文件。

    日志格式

    此时的aof文件已经和只开启AOF持久化文件不一样了,上半部分是RDB持久化的数据,下半部分是AOF格式数据。

    显而易见前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。

    展开全文
  • 现在看log日志有几条CRIT级别的报错 <pre><code> [18:30:49 CST 2020/08/05] [CRIT] (mongoshake/executor.(*Executor).execute:112) Replayer-1, executor-1, oplog for namespace[questionnaire.question] op[i] ...
  • 通过查看度假后台的日志,发现在发送全量dump通知的时候抛出了"dead lock detached"的错误,由于后台代码此处并没有采用多线程,进而怀疑是DB死锁,于是请求老何支援。查看DB的错误日志,发现是后台系统和...
    [b]问题描述[/b]
    度假后台在更新完DB的数据后会通知dumper进行一次全量dump,但不时会遇到dumper没有收到通知的情况。通过查看度假后台的日志,发现在发送全量dump通知的时候抛出了"dead lock detached"的错误,由于后台代码此处并没有采用多线程,进而怀疑是DB死锁,于是请求老何支援。查看DB的错误日志,发现是后台系统和dumper的sql产生了死锁。

    死锁原因
    产生死锁的两项DB操作分别如下:
    1. 度假后台:发送全量dump通知前的数据更新会对名为route的表进行循环update操作,且整个循环被保持在一个事务当中,整个事务成功后才会发送全量dump通知,否则rollback。

    2. dumper:dumper除了监听全量dump通知之外,还会对route表中update_flag字段为true的记录进行增量dump,dump完成后会将update_flag重新置为false,使用的sql如下。

    update route set update_flag = false where update_flag = true and id in (...);

    其中,括号内的id为无序,这也是产生死锁的关键。
    假设度假后台代码中是按ID升序更新,更新序列为"1,2,3,4,5,6...",而dumper某次增量dump需要更新ID为3,5的记录,且更新序列为所"5,3",那么将可能出现下面的情况。
    度假后台依次更新ID为1,2,3,4的记录,并且获得了这四条记录的行锁,此时需要获取ID为5的记录的行锁;而不巧dumper的update操作正好刚更新完ID为5的记录,正需要获取ID为3的记录的行锁...
    于是死锁产生了

    [b]解决办法[/b]
    解决办法很简单,只需要给dumper的"where id in (...)" sql中的ID排个序,且保证其顺序与度假后台事务中的更新顺序一致。这样,上述的死锁情况就会变为:
    度假后台需要顺序获得ID为"1,2,3,4,5,6,..."的行锁,dumper则需要顺序获得ID为"3,5"的行锁,无论两项操作谁先开始,都最多只可能有一项操作处于等待锁的状态。

    另一种解决方法是,将dumper中的"where id in (...)"操作修改为每个ID执行一条SQL,且该批量更新操作无需保证其事务性。在保证使用同一数据库连接的前提下,拆分开的多个update操作应该不会比之前的"update ...按 where id in (...)"操作慢多少。小插曲:在比较这两种操作的性能时,老何提到说"集中型的操作会造成资源占用的尖峰,如果这个尖峰引起了系统资源的紧张,那么执行的效率或许还不如把操作切分为多个小份,那样每一份操作会很快地执行完"。

    [b]后续思考[/b]
    在了解了死锁产生的原因之后,我对数据库获取和释放行锁的顺序有了一丝疑问:

    1.为什么产生死锁的两项操作不会在一开始就把需要的行锁全部拿到,从而杜绝和其他操作产生死锁的可能;

    2.为什么释放锁的时候不是用完一个释放一个,而是要等所有操作都进行完了才一起释放?

    于是上stackoverflow发了个问([url]http://stackoverflow.com/questions/11454638/how-do-the-db-lock-rows-and-release-them[/url]).
    答案里提到,获取和释放锁的顺序和DB的数据库隔离级别有关。在默认的隔离级别Read Committed下,锁的获取和释放就像问题中所描述的那样,获取的时候会依次获取,而释放则统一在操作完成后释放。如果是使用最为严格的Serializable隔离级别,那么情况就会变成和我第一个疑问中描述的那样:在操作的一开始便把需要的行锁全部拿到,直到操作完成才全部释放,但是这样自然会造成性能的下降。

    至于我第二个疑问所描述的情况,则是无法保证事务性的,如果操作还未完成便释放部分行锁的话,其他操作可能会这一部分记录做修改,从而破坏了整个事务。
    展开全文
  • ETL 基础知识

    2021-01-08 17:55:48
    ETL 基础知识1. 基础概念1.1 背景1.2 定义1.2.1 数据的抽取 (Extract)1.2.2 ... ETL 日志, 警告发送3.1 ETL 日志3.2 警告发送4. ETL 工具4.1 为什么要使用 ETL 工具4.2 ETL 工具选择依据4.3 主流 ETL 工具推荐 1. 基础

    1. 基础概念

    1.1 背景

    1. 企业自身的需要: 随着企业的发展, 加快了数据信息化时代的到来, 各企业中业务系统之间的数据流通阻塞, 业务集成困难, 数据共享不便等. 导致了 “数据孤岛” 现象. 对企业进行数据分析利用, 报表开发, 分析挖掘等带来了巨大困难.
    2. 社会发展的需求: 现在随着各个领域的发展, 国家倡导一体化平台的建设. 主要解决 “数据孤岛” 带来的一些问题和弊端.

    在这里插入图片描述

    一体化平台的建设一个必要条件就是数据的一体化. 实现企业全局数据的系统化运作管理 (信息孤岛、数据统计、数据分析、数据挖掘). 为 DSS (决策支持系统)、BI (商务智能)、经营分析系统等深度开发应用奠定基础, 挖掘数据价值, 企业会开始着手建立数据仓库, 数据中台. 将相互分离的业务系统的数据源整合在一起, 建立一个统一的数据采集、处理、存储、分发、共享中心.

    在这里插入图片描述

    ETL 是 BI 项目重要的一个环节. 通常情况下, 在 BI 项目中 ETL 会花掉整个项目至少 1/3 的时间, ETL 设计的好坏直接关接到 BI 项目的成败.

    1.2 定义

    ETL 是将业务系统的数据经过抽取 (Extract)、清洗转换 (ransform) 之后加载 (Load) 到数据仓库的过程, 目的是将企业中的分散、零乱、标准不统一的数据整合到一起, 为企业的决策提供分析依据.

    ETL 的设计分三部分: 数据抽取, 数据的清洗转换, 数据的加载.

    设计 ETL 便从这三部分出发: 数据的抽取是从各个不同的数据源抽取到 ODS (Operational Data Store, 操作型数据存储) 中 —— 这个过程也可以做一些数据的清洗和转换), 在抽取的过程中需要挑选不同的抽取方法, 尽可能的提高 ETL 的运行效率. ETL 三个部分中, 花费时间最长的是 “T” (Transform, 清洗、转换) 的部分, 一般情况下这部分工作量是整个 ETL 的 2/3. 数据的加载一般在数据清洗完了之后直接写入 DW (Data Warehousing, 数据仓库) 中去.

    在这里插入图片描述

    1.2.1 数据的抽取 (Extract)

    1. 确定数据源, 需要确定从哪些源系统进行数据抽取
    2. 定义数据接口, 对每个源文件及系统的每个字段进行详细说明
    3. 确定数据抽取的方法: 是主动抽取还是由源系统推送? 是增量抽取还是全量抽取? 是按照每日抽取还是按照每月抽取? 
    

    1.2.2 数据的清洗转换 (Cleaning、Transform)

    一般情况下, 数据仓库分为 ODS、DW 两部分. 通常的做法是从业务系统到 ODS 做清洗, 将脏数据和不完整数据过滤掉, 在从 ODS 到 DW 的过程中转换, 进行一些业务规则的计算和聚合. ODS 也就是

    1. 数据清洗: 
    	1.1 不完整的数据
    	1.2 错误的数据
    	1.3 重复的数据
    2. 数据转换: 
    	2.1 空值处理: 可捕获字段空值, 进行加载或替换为其他含义数据, 或数据分流问题库
    	2.2 数据标准: 统一元数据、统一标准字段、统一字段类型定义
    	2.3 数据拆分: 依据业务需求做数据拆分, 如身份证号, 拆分区划、出生日期、性别等
    	2.4 数据验证: 时间规则、业务规则、自定义规则
    	2.5 数据替换: 对于因业务因素, 可实现无效数据、缺失数据的替换
    	2.6 数据关联: 关联其他数据或数学, 保障数据完整性
    

    1.2.3 数据加载 (loading)

    将数据缓冲区的数据直接加载到数据库对应表中, 如果是全量方式则采用 LOAD 方式, 如果是增量则根据业务规则 MERGE 进数据库.

    1.3 常见的实现方式

    1. 借助 ETL 工具: 如 Oracle 的 OWB、SQL Server 2000 的 DTS、SQL Server2005 的 SSIS 服务、Informatic 等实现. 借助工具可以快速的建立起 ETL 工程, 屏蔽了复杂的编码任务, 提高了速度, 降低了难度, 但是缺少灵活性.
    2. SQL 方式实现: 优点是灵活, 提高 ETL 运行效率, 但是编码复杂, 对技术要求比较高.
    3. ETL 工具和 SQL 相结合: 综合了前面二种的优点, 会极大地提高 ETL 的开发速度和效率.

    2. 模式介绍

    ETL 有四种主要实现模式: 触发器模式, 增量字段, 全量同步, 日志比对.

    2.1 触发器模式

    触发器方式是普遍采取的一种增量抽取机制. 该方式是根据抽取要求, 在要被抽取的源表上建立插入、修改、删除 3 个触发器, 每当源表中的数据发生变化, 就被相应的触发器将变化的数据写入一个增量日志表, ETL 的增量抽取则是从增量日志表中而不是直接在源表中抽取数据, 同时增量日志表中抽取过的数据要及时被标记或删除. 为了简单起见, 增量日志表一般不存储增量数据的所有字段信息, 而只是存储源表名称、更新的关键字值和更新操作类型 (insert、update或delete), ETL 增量抽取进程首先根据源表名称和更新的关键字值, 从源表中提取对应的完整记录, 再根据更新操作类型, 对目标表进行相应的处理.

    优点: 数据抽取的性能高, ETL 加载规则简单, 速度快, 不需要修改业务系统表结构, 可以实现数据的递增加载.

    缺点: 要求业务表建立触发器, 对业务系统有一定的影响, 容易对源数据库构成威胁.

    2.2 增量字段

    增量字段方式来捕获变化数据, 原理就是在源系统业务表数据表中增加增量字段, 增量字段可以是时间字段, 同时也可以是自增长字段 (如 Oracle 的序列), 设计要求就是源业务系统中数据新增或者被修改时, 增量字段就会产生变化, 时间戳字段就会被修改为相应的系统时间, 自增长字段就会增加.

    每当ETL工具进行增量数据获取时, 只需比对最近一次数据抽取的增量字段值, 就能判断出来哪些是新增数据, 哪些是修改数据.这种数据抽取方式的优点就是抽取性能比较高, 判断过程比较简单, 最大的局限性就是由于某些数据库在进行设计的时候, 未考虑到增量字段, 需要对业务系统进行改造, 基于数据库其他方面的原因, 还有可能出现漏数据的情况.

    优点: 同触发器方式一样, 时间戳方式的性能也比较好, ETL 系统设计清晰, 源数据抽取相对清楚简单, 可以实现数据的递增加载.

    缺点: 时间戳维护需要由业务系统完成, 对业务系统也有很大的侵入性 (加入额外的时间戳字段), 特别是对不支持时间戳的自动更新的数据库, 还要求业务系统进行额外的更新时间戳操作; 另外, 无法捕获对时间戳以前数据的 delete 和 update 操作, 在数据准确性上受到了一定的限制.

    2.3 全量同步

    全量同步又叫全表删除插入方式, 是指每次抽取前先删除目标表数据, 抽取时全新加载数据. 该方式实际上将增量抽取等同于全量抽取. 对于数据量不大, 全量抽取的时间代价小于执行增量抽取的算法和条件代价时, 可以采用该方式.

    同步流程:
    在这里插入图片描述

    优点: 对已有系统表结构不产生影响, 不需要修改业务操作程序, 所有抽取规则由ETL完成, 管理维护统一, 可以实现数据的递增加载, 没有风险.

    缺点: ETL 比对较复杂, 设计较为复杂, 速度较慢. 与触发器和时间戳方式中的主动通知不同, 全表比对方式是被动的进行全表数据的比对, 性能较差.当表中没有主键或唯一列且含有重复记录时, 全表比对方式的准确性较差.

    2.4 日志比对

    日志比对的方式是通过获取数据库层面的日志来捕获到变化的数据, 不需要改变源业务系统数据库相关表结构, 数据同步的效率比较高, 同步的及时性也比较快, 最大的问题就是前面所提到的不同的数据库的数据库日志文件结构存在较大的差异性, 实施分析起来难度比较大, 同时需要具备访问源业务库日志表文件的权限, 存在一定的风险性, 所以这种方式有很大的局限性.

    日志比对方式中比较成熟的技术是 Oracle 的 CDC (Changed Data Capture) 技术, 作用同样是能够捕获到上一次抽取之后的产生的相关变化数据, 当 CDC 对源业务表进行新增、更新和删除等相关操作的时就可以捕获到相关变化的数据, 相对于增量字段方式, CDC 方式能够较好的捕获到删除数据, 并写入相关数据库日志表, 然后再通过视图或者别的某种可操作的方式将捕获到的变化同步到数据仓库当中去.

    优点: ETL 同步效率较高, 不需要修改业务系统表结构, 可以实现数据的递增加载.

    缺点: 业务系统数据库版本与产品不统一, 难以统一实现, 实现过程相对复杂, 并且需深入研究方能实现. 或者通过第三方工具实现, 一般都是商业软件, 而且费用较高.

    2.5 模式对比

    增量机制 兼容性 完备性 抽取性能 源库压力 源库改动量 实现难度
    触发器 关系型数据库 容易
    增量字段 关系型数据库.具有”字段”结构的其它数据格式 较优 容易
    全表同步 任何数据格式 极差 容易
    日志比对 关系型数据库 (oracle/mysql) 较优 较难

    3. ETL 日志, 警告发送

    3.1 ETL 日志

    ETL 日志分为三类:

    1. 执行过程日志: 这一部分日志是在 ETL 执行过程中每执行一步的记录, 记录每次运行每一步骤的起始时间, 影响了多少行数据, 流水账形式.
    2. 错误日志: 当某个模块出错的时候写错误日志, 记录每次出错的时间、出错的模块以及出错的信息等。
    3. 日志是总体日志: 只记录 ETL 开始时间、结束时间是否成功信息. 如果使用 ETL 工具, ETL 工具会自动产生一些日志, 这一类日志也可以作为 ETL 日志的一部分.

    记录日志的目的是随时可以知道 ETL 运行情况, 如果出错了, 可以知道哪里出错.

    3.2 警告发送

    如果 ETL 出错了, 不仅要形成 ETL 出错日志, 而且要向系统管理员发送警告。发送警告的方式多种, 一般常用的就是给系统管理员发送邮件, 并附上出错的信息, 方便管理员排查错误.

    ETL 是 BI 项目的关键部分, 也是一个长期的过程, 只有不断的发现问题并解决问题, 才能使 ETL 运行效率更高, 为 BI 项目后期开发提供准确与高效的数据.

    4. ETL 工具

    4.1 为什么要使用 ETL 工具

    当数据来自不同的物理主机, 这时候如果使用SQL语句去处理的话就显得比较吃力且开销也更大.

    数据来源可以是各种不同的数据库或者文件, 这时候需要先把他们整理成统一的格式后才可以进行数据的处理, 这一过程用代码实现显然有些麻烦.

    在数据库中我们当然可以使用存储过程去处理数据, 但是处理海量数据的时候存储过程显然比较吃力, 而且会占用较多数据库的资源, 这可能会导致数据库资源不足, 进而影响数据库的性能.

    4.2 ETL 工具选择依据

    1. 对平台的支持程度
    2. 抽取和装载的性能是不是较高, 且对业务系统的性能影响大不大, 侵入性高不高
    3. 对数据源的支持程度
    4. 是否具有良好的集成性和开放性
    5. 数据转换和加工的功能强不强
    6. 是否具有管理和调度的功能
    

    4.3 主流 ETL 工具推荐

    PDI (KETTLE) DATASTAGE
    免费 IBM 商业软件
    开源产品, 使用纯JAVA代码编写的 ETL 工具 专业的 ETL 工具, 价格不菲
    跨平台 适合大规模的 ETL 应用
    扩展性好

    参考网址:
    [1]: https://www.cnblogs.com/yjd_hycf_space/p/7772722.html
    [2]: https://blog.csdn.net/jianzhang11/article/details/104240047/

    展开全文
  • 之前给业务排查的时候发现,业务上存在大量的全量查询,其中很多信息都是无用的,采用全量查询存在以下几个方面问题:查询数据量大,导致发送时间长,在数据库中经常看到慢查询日志,经常需要分析当前业务采用...
  • 阿里云直播 笔记

    2016-09-10 16:47:00
    dubbo 潘多拉容器 edas jenkins自动部署 tddl 读写分离 drds 垂直拆分 拆库 全量更新 水平拆分 拆表 从业务角度来拆分 ...异步发送 日志 、监测数据 事务消息顺序消息(全局消息 区域消息)消息回溯 实时...
  • 最近在用kafka做消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。 问题: hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万左右...
  • kafka:发现kafka丢消息后的排查

    千次阅读 2018-10-05 14:13:26
     最近在用kafka做消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。 问题:  hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万...
  • <div><p>公司名称(必填) 德施曼 ...logcat关于执行固件升级过程的全量日志已通过邮件发送给 tss-miot.com</p><p>该提问来源于开源项目:MiEcosystem/miot-plugin-sdk</p></div>
  • 阿里canal

    2021-02-18 21:58:48
    增量日志数据的订阅 消费和解析 可以订阅到mysql二进制日志的变化 然后可以拿到数据进行消费 ,历史数据无效 只能通过其他方式进行全量同步 io 和 thread线程间隔一下执行一次 主从同步有时间的延迟 不是立刻马上的...
  • canal是由Alibaba开源的一个基于binlog的增量日志组件,其核心原理是canal伪装成Mysql的slave,发送dump协议获取binlog,解析并存储起来给客户端消费。 优点:可以同步任何非查询类操作。DDL和DML语句(除了数据...
  • 方案简洁,mysql端发生数据变更后只需要将对应日志发送给接收端,不必考虑数据一致性问题。 缺点 是否能够过滤掉不必同步的数据有待考察 只支持监听消息变更,不支持将原有数据进行同步 消息队列方案 优点 可以...
  • 读取RDBMS增量日志的方式来 实时获取增量数据日志,并支持全量拉取; 基于logtash,flume,filebeat等抓取工具来实时获得数据,以可视化的方式对数据进行结构化输出; 以下为具体实现原理 主要模块如下: 日志...
  • 然后会在本机部署一个agent用于抓取日志发送到jstorm集群中用于分析等。那这里我们的应用系统就对应消息队列中的生产者producer,jstorm集群就对应消费者consumer。 所以说白了其实消息队列和log4j这些组件都是日志...
  • 基础12 ElasticSearch document的全量替换、强制创建 基础13 ElasticSearch 基于_version进行乐观锁并发控制 基础14 Elastic Search version进行乐观锁并发控 基础15 Elastic Search 基于external version进行...
  • 17、Rolling实时日志:支持在线查看调度结果,并且支持以Rolling方式实时查看执行器输出的完整的执行日志; 18、GLUE:提供Web IDE,支持在线开发任务逻辑代码,动态发布,实时编译生效,省略部署上线的过程。支持30...
  • [系统架构]功能增强,Dump命令支持全量数据导出和部分数据导出 [系统架构]功能增强,Dump命令支持对数据和文件信息的合并操作 [系统架构]系统增强,改用Instrumentation实现jar包加载 [系统架构]系统增强,webServer...
  • 18、Rolling实时日志:支持在线查看调度结果,并且支持以Rolling方式实时查看执行器输出的完整的执行日志; 19、GLUE:提供Web IDE,支持在线开发任务逻辑代码,动态发布,实时编译生效,省略部署上线的过程。支持30...
  • 默认每 20 秒进行一次全量检查。(TabletChecker.CHECK_INTERVAL_MS) </li><li> 在每次检查前,如果发现 TS 中正在调度或排队的 Tablet 数量超过 5000(TabletChecker.MAX_SCHEDULING_TABLETS)&#...
  • 针对向后端发送接口请求:在客户端初始化 WebView 的同时,直接由 Native 开始网络请求数据,当页面初始化完成后,向 Native 获取其代理请求的数据。 </li><li> 针对加载的 js 动态拼接 ...

空空如也

空空如也

1 2
收藏数 23
精华内容 9
关键字:

发送全量日志