文档章节

Redis部署,高可用与分布式集群部署

梦想没有终点
 梦想没有终点
发布于 2016/02/03 10:47
字数 4434
阅读 12
收藏 0

redis 的持久化:

快照(snapshot):特定时间、特定命令、特定条件来触发,把某一时刻在内存中的数据全部写出到硬盘当中去。

快照的时间不是实时的,可能会有数据的丢失。

在宕机之后,会把全部dump文件中的数据读入到内存中,会I/O密集。


AOF(append only file):每一次更新都会记录日志。日志文件是在快照的基础上来写的。
(在AOF这里的“快照”跟上面的“快照”不是一个东西。)


redis的 rdb 和 aof 持久化的区别:

参考:http://ptc.35.com/?p=275


aof,rdb是两种 redis持久化的机制。用于crash后,redis的恢复。

rdb的特性如下:

Code:

fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来。
save, shutdown, slave 命令会触发这个操作。
粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复。

aof有如下特性:

Code:

把写操作指令,持续的写到一个类似日志文件里。(类似于从postgresql等数据库导出sql一样,只记录写操作)
粒度较小,crash之后,只有crash之前没有来得及做日志的操作没办法恢复。

两种区别就是,一个是持续的用日志记录写操作,crash后利用日志恢复;一个是平时写操作的时候不触发写,只有手动提交save命令,或者是关闭命令时,才触发备份操作。

选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(aof),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了。


Redis持久化实践及灾难恢复模拟:

参考:http://heylinux.com/archives/1932.html

一、对Redis持久化的探讨与理解

目前Redis持久化的方式有两种: RDB 和 AOF

首先,我们应该明确持久化的数据有什么用,答案是用于重启后的数据恢复。
Redis是一个内存数据库,无论是RDB还是AOF,都只是其保证数据恢复的措施。
所以Redis在利用RDB和AOF进行恢复的时候,都会读取RDB或AOF文件,重新加载到内存中。

RDB就是Snapshot快照存储,是默认的持久化方式。
可理解为半持久化模式,即按照一定的策略周期性的将数据保存到磁盘。
对应产生的数据文件为dump.rdb,通过配置文件中的save参数来定义快照的周期。
下面是默认的快照设置:

1 save 900 1    #当有一条Keys数据被改变时,900秒刷新到Disk一次
2 save 300 10   #当有10条Keys数据被改变时,300秒刷新到Disk一次
3 save 60 10000 #当有10000条Keys数据被改变时,60秒刷新到Disk一次

Redis的RDB文件不会坏掉,因为其写操作是在一个新进程中进行的。
当生成一个新的RDB文件时,Redis生成的子进程会先将数据写到一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件。
这样在任何时候出现故障,Redis的RDB文件都总是可用的。

同时,Redis的RDB文件也是Redis主从同步内部实现中的一环。
第一次Slave向Master同步的实现是:
Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
第二次以及以后的同步实现是:
Master将变量的快照直接实时依次发送给各个Slave。
但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。

可以很明显的看到,RDB有它的不足,就是一旦数据库出现问题,那么我们的RDB文件中保存的数据并不是全新的。
从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。

AOF(Append-Only File)比RDB方式有更好的持久化性。
由于在使用AOF持久化方式时,Redis会将每一个收到的写命令都通过Write函数追加到文件中,类似于MySQL的binlog。
当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
对应的设置参数为:
$ vim /opt/redis/etc/redis_6379.conf

1 appendonly yes       #启用AOF持久化方式
2 appendfilename appendonly.aof #AOF文件的名称,默认为appendonly.aof
3 # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。
4 appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐的方式。
5 # appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。

AOF的完全持久化方式同时也带来了另一个问题,持久化文件会变得越来越大。
比如我们调用INCR test命令100次,文件中就必须保存全部的100条命令,但其实99条都是多余的。
因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
为了压缩AOF的持久化文件,Redis提供了bgrewriteaof命令。
收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件,以此来实现控制AOF文件的增长。
由于是模拟快照的过程,因此在重写AOF文件时并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
对应的设置参数为:
$ vim /opt/redis/etc/redis_6379.conf

1 no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
2 auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
3 auto-aof-rewrite-min-size 64mb  #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

到底选择什么呢?下面是来自官方的建议:
通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。

在数据恢复方面:
RDB的启动时间会更短,原因有两个:
一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。

二、灾难恢复模拟

既然持久化的数据的作用是用于重启后的数据恢复,那么我们就非常有必要进行一次这样的灾难恢复模拟了。
据称如果数据要做持久化又想保证稳定性,则建议留空一半的物理内存。因为在进行快照的时候,fork出来进行dump操作的子进程会占用与父进程一样的内存,真正的copy-on-write,对性能的影响和内存的耗用都是比较大的。
目前,通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足,达到了数据可持久化。
即Master上Snapshot和AOF都不做,来保证Master的读写性能,而Slave上则同时开启Snapshot和AOF来进行持久化,保证数据的安全性。

首先,修改Master上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf

1 #save 900 1 #禁用Snapshot
2 #save 300 10
3 #save 60 10000
4
5 appendonly no #禁用AOF

接着,修改Slave上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf

01 save 900 1 #启用Snapshot
02 save 300 10
03 save 60 10000
04
05 appendonly yes #启用AOF
06 appendfilename appendonly.aof #AOF文件的名称
07 # appendfsync always
08 appendfsync everysec #每秒钟强制写入磁盘一次
09 # appendfsync no 
10
11 no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作
12 auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
13 auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值

分别启动Master与Slave
$ /etc/init.d/redis start

启动完成后在Master中确认未启动Snapshot参数
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

然后通过以下脚本在Master中生成25万条数据:
dongguo@redis :/opt/redis/data/6379$ cat redis-cli-generate.temp.sh

01 #!/bin/bash
02
03 REDISCLI="redis-cli -a slavepass -n 1 SET"
04 ID=1
05
06 while(($ID<50001))
07 do
08   INSTANCE_NAME="i-2-$ID-VM"
09   UUID=`cat /proc/sys/kernel/random/uuid`
10   PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" bc`.`echo "$RANDOM % 255 + 1" bc`.`echo "$RANDOM % 255 + 1" bc`\
11   CREATED=`date "+%Y-%m-%d %H:%M:%S"`
12
13   $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
14   $REDISCLI vm_instance:$ID:uuid "$UUID"
15   $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
16   $REDISCLI vm_instance:$ID:created "$CREATED"
17
18   $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"
19
20   ID=$(($ID+1))
21 done

dongguo@redis :/opt/redis/data/6379$ ./redis-cli-generate.temp.sh

在数据的生成过程中,可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件,之后就通过增量传输命令的方式给Slave了。
dump.rdb文件没有再增大。
dongguo@redis :/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

而Slave上则可以看到dump.rdb文件和AOF文件在不断的增大,并且AOF文件的增长速度明显大于dump.rdb文件。
dongguo@redis-slave:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb

等待数据插入完成以后,首先确认当前的数据量。
redis 127.0.0.1:6379> info

01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
05 multiplexing_api:epoll
06 gcc_version:4.4.5
07 process_id:27623
08 run_id:e00757f7b2d6885fa9811540df9dfed39430b642
09 uptime_in_seconds:1541
10 uptime_in_days:0
11 lru_clock:650187
12 used_cpu_sys:69.28
13 used_cpu_user:7.67
14 used_cpu_sys_children:0.00
15 used_cpu_user_children:0.00
16 connected_clients:1
17 connected_slaves:1
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33055824
22 used_memory_human:31.52M
23 used_memory_rss:34717696
24 used_memory_peak:33055800
25 used_memory_peak_human:31.52M
26 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:0
30 changes_since_last_save:250000
31 bgsave_in_progress:0
32 last_save_time:1348677645
33 bgrewriteaof_in_progress:0
34 total_connections_received:250007
35 total_commands_processed:750019
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:246
43 vm_enabled:0
44 role:master
45 slave0:10.6.1.144,6379,online
46 db1:keys=250000,expires=0

当前的数据量为25万条key,占用内存31.52M。

然后我们直接Kill掉Master的Redis进程,模拟灾难。
dongguo@redis :/opt/redis/data/6379$ sudo killall -9 redis-server

我们到Slave中查看状态:
redis 127.0.0.1:6379> info

01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
05 multiplexing_api:epoll
06 gcc_version:4.4.5
07 process_id:13003
08 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
09 uptime_in_seconds:1627
10 uptime_in_days:0
11 lru_clock:654181
12 used_cpu_sys:29.69
13 used_cpu_user:1.21
14 used_cpu_sys_children:1.70
15 used_cpu_user_children:1.23
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047696
22 used_memory_human:31.52M
23 used_memory_rss:34775040
24 used_memory_peak:33064400
25 used_memory_peak_human:31.53M
26 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:3308
31 bgsave_in_progress:0
32 last_save_time:1348718951
33 bgrewriteaof_in_progress:0
34 total_connections_received:4
35 total_commands_processed:250308
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:694
43 vm_enabled:0
44 role:slave
45 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 master_host:10.6.1.143
51 master_port:6379
52 master_link_status:down
53 master_last_io_seconds_ago:-1
54 master_sync_in_progress:0
55 master_link_down_since_seconds:25
56 slave_priority:100
57 db1:keys=250000,expires=0

可以看到master_link_status的状态已经是down了,Master已经不可访问了。
而此时,Slave依然运行良好,并且保留有AOF与RDB文件。

下面我们将通过Slave上保存好的AOF与RDB文件来恢复Master上的数据。

首先,将Slave上的同步状态取消,避免主库在未完成数据恢复前就重启,进而直接覆盖掉从库上的数据,导致所有的数据丢失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK

确认一下已经没有了master相关的配置信息:
redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
05 multiplexing_api:epoll
06 gcc_version:4.4.5
07 process_id:13003
08 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
09 uptime_in_seconds:1961
10 uptime_in_days:0
11 lru_clock:654215
12 used_cpu_sys:29.98
13 used_cpu_user:1.22
14 used_cpu_sys_children:1.76
15 used_cpu_user_children:1.42
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047696
22 used_memory_human:31.52M
23 used_memory_rss:34779136
24 used_memory_peak:33064400
25 used_memory_peak_human:31.53M
26 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348719252
33 bgrewriteaof_in_progress:0
34 total_connections_received:4
35 total_commands_processed:250311
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:1119
43 vm_enabled:0
44 role:master
45 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 db1:keys=250000,expires=0

在Slave上复制数据文件:
dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb

将data.tar上传到Master上,尝试恢复数据:
可以看到Master目录下有一个初始化Slave的数据文件,很小,将其删除。
dongguo@redis:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
dongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb

然后解压缩数据文件:
dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb

启动Master上的Redis;
dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...

查看数据是否恢复:
redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
05 multiplexing_api:epoll
06 gcc_version:4.4.5
07 process_id:16959
08 run_id:6e5ba6c053583414e75353b283597ea404494926
09 uptime_in_seconds:22
10 uptime_in_days:0
11 lru_clock:650292
12 used_cpu_sys:0.18
13 used_cpu_user:0.20
14 used_cpu_sys_children:0.00
15 used_cpu_user_children:0.00
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047216
22 used_memory_human:31.52M
23 used_memory_rss:34623488
24 used_memory_peak:33047192
25 used_memory_peak_human:31.52M
26 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:0
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348680180
33 bgrewriteaof_in_progress:0
34 total_connections_received:1
35 total_commands_processed:1
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:0
43 vm_enabled:0
44 role:master
45 db1:keys=250000,expires=0

可以看到25万条数据已经完整恢复到了Master上。

此时,可以放心的恢复Slave的同步设置了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK

查看同步状态:
redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
05 multiplexing_api:epoll
06 gcc_version:4.4.5
07 process_id:13003
08 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
09 uptime_in_seconds:2652
10 uptime_in_days:0
11 lru_clock:654284
12 used_cpu_sys:30.01
13 used_cpu_user:2.12
14 used_cpu_sys_children:1.76
15 used_cpu_user_children:1.42
16 connected_clients:2
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33056288
22 used_memory_human:31.52M
23 used_memory_rss:34766848
24 used_memory_peak:33064400
25 used_memory_peak_human:31.53M
26 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348719252
33 bgrewriteaof_in_progress:1
34 total_connections_received:6
35 total_commands_processed:250313
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:12217
43 vm_enabled:0
44 role:slave
45 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 master_host:10.6.1.143
51 master_port:6379
52 master_link_status:up
53 master_last_io_seconds_ago:0
54 master_sync_in_progress:0
55 slave_priority:100
56 db1:keys=250000,expires=0

master_link_status显示为up,同步状态正常。

在此次恢复的过程中,我们同时复制了AOF与RDB文件,那么到底是哪一个文件完成了数据的恢复呢?
实际上,当Redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
1. 如果只配置AOF,重启时加载AOF文件恢复数据;
2. 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;
3. 如果只配置RDB,启动是将加载dump文件恢复数据。

也就是说,AOF的优先级要高于RDB,这也很好理解,因为AOF本身对数据的完整性保障要高于RDB。

在此次的案例中,我们通过在Slave上启用了AOF与RDB来保障了数据,并恢复了Master。

但在我们目前的线上环境中,由于数据都设置有过期时间,采用AOF的方式会不太实用,过于频繁的写操作会使AOF文件增长到异常的庞大,大大超过了我们实际的数据量,这也会导致在进行数据恢复时耗用大量的时间。
因此,可以在Slave上仅开启Snapshot来进行本地化,同时可以考虑将save中的频率调高一些或者调用一个计划任务来进行定期bgsave的快照存储,来尽可能的保障本地化数据的完整性。
在这样的架构下,如果仅仅是Master挂掉,Slave完整,数据恢复可达到100%。
如果Master与Slave同时挂掉的话,数据的恢复也可以达到一个可接受的程度。


© 著作权归作者所有

梦想没有终点
粉丝 2
博文 31
码字总数 28266
作品 0
海淀
私信 提问
架构师必备词汇和知识点

01 高可用 负载均衡(负载均衡算法) 反向代理 服务隔离 服务限流 服务降级(自动优雅降级) 失效转移 超时重试(代理超时、容器超时、前端超时、中间件超时、数据库超时、NoSql超时) 回滚机...

t4i2b10X4c22nF6A
2017/11/24
0
0
这可能是目前最全的Redis高可用技术解决方案总结

作者介绍 张冬洪,极数云舟数据库架构师,极数学院联合创始人,前新浪微博高级DBA,Redis中国用户组主席,阿里云MVP。 本文主要针对Redis常见的几种使用方式及其优缺点展开分析。 Redis的几种...

张冬洪
2018/08/20
0
0
基于Docker的Redis高可用集群搭建(redis-sentinel)

前言   之前介绍了用docker来搭建redis主从环境,但这只是对数据添加了从库备份(主从复制),当主库down掉的时候,从库是不会自动升级为主库的,也就是说,该redis主从集群并非是高可用的。...

mario阿东
2018/07/06
0
0
亿级流量电商详情页系统的大型高并发与高可用缓存架构实战

对于高并发的场景来说,比如电商类,o2o,门户,等等互联网类的项目,缓存技术是Java项目中最常见的一种应用技术。然而,行业里很多朋友对缓存技术的了解与掌握,仅仅停留在掌握redis/memca...

登录404
2017/06/05
1K
0
Redis 的几种常见使用方式

Redis 的几种常见使用方式包括: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster Redis 自研 Redis 单副本,采用单个 Redis 节点部署架构,没有备用节点实时同步数...

Forande
2018/08/27
0
0

没有更多内容

加载失败,请刷新页面

加载更多

kubernetes API 访问控制在阿里云容器服务(ACK)上的实践

提起K8s API的访问控制,很多同学应该都会想到RBAC,这是K8s用来做权限控制的方法,但是K8s对API的访问控制却不止于此,今天我们就来简单介绍下K8s的访问控制以及ACK如何利用这套方法提供便捷...

zhaowei121
15分钟前
0
0
从HelloWorld看Knative Serving代码实现

概念先知 官方给出的这几个资源的关系图还是比较清晰的: 1.Service: 自动管理工作负载整个生命周期。负责创建route,configuration以及每个service更新的revision。通过Service可以指定路由流...

迷你芊宝宝
15分钟前
0
0
如何防止http请求数据被篡改

故事的开始,面试官问了我一个问题: 如何防止http请求中数据被篡改? 回答: 1.设置客户端IP黑/白名单 1.1.客户端所有请求,请求到代理服务器(nginx),代理服务器维护黑/白名单的ip,决定是...

太猪-YJ
19分钟前
0
0
好程序员大数据笔记之:Hadoop集群搭建

在学习大数据的过程中,我们接触了很多关于Hadoop的理论和操作性的知识点,尤其在近期学习的Hadoop集群的搭建问题上,小细节,小难点拼频频出现,所以,今天集中总结以下笔记,希望对各位同学...

好程序员IT
26分钟前
0
0
MySql用navcat连接时报错 2509

在8版本以后的MySql默认的加密方式都改为了caching_sha2_password 因此进入mysql的命令行更改加密方式即可 ALTER USER 'root'@'localhost' IDENTIFIED BY 'password' PASSWORD EXPIRE NEVER......

lanyu96
28分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部