Redis高可用集群-哨兵模式(Redis-Sentinel)搭建配置教程【Windows环境】

=================================================

人工智能教程。零基础!通俗易懂!风趣幽默!大家可以看看是否对自己有帮助!
点击查看高清无码教程

=================================================

No cross,no crown . 不经历风雨,怎么见彩虹。

Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等。

Redis-sentinel简介

Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel。

Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。

该系统执行以下三个任务:

  • 监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
  • 提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知。
  • 自动故障迁移(Automatic failover): (1)当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,他会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;
    (2)客户端试图连接失败的主服务器时,集群也会向客服端返回新主服务器的地址,是的集群可以使用新主服务器代替失效服务器。

sentinel的分布式特性

Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。

单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后(sentinel本身也有单点问题,single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群,这样有几个好处:

  • 有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;

  • 如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);

  • 如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息

一个健壮的部署至少需要三个哨兵实例。

三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。【本次讲解是一个机器上进行搭建,和多级是一个道理】

Redis-sentinel搭建

  1. 环境
Windows10
Redis-x64-3.2.100


本次搭建说明:
master:127.0.0.1:6379 【初始化master】

slave:127.0.0.1:6380  127.0.0.1:6381

sentinel:127.0.0.1:26379  127.0.0.1:26380  127.0.0.1:26381

  1. 安装和基本配置

因为之前已经介绍过Redis集群的主从配置,里面有安装和基本配置,所以这里不做介绍,不懂的请查看:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】

  1. Sentinel配置
    根据安装和基本配置,已经有了主从配置 ,对应文件夹Redis6379~Redis6381。然后在每个文件夹下面新增 一个名为 sentinel.conf 的文件。配置内容如下:
# 这个是Redis6379配置内容,其他文件同理新增然后改一下端口即可,26380,和 26381。

#当前Sentinel服务运行的端口
port 26379  
# 哨兵监听的主服务器 
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover  
sentinel failover-timeout mymaster 10000  
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1


配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到(master节点中有关于slave的消息)。

为了更清楚每一行配置的含义,对每个选项的含义进行简单介绍:

sentinel monitor [master-group-name] [ip] [port] [quorum]

  • master-group-name:master名称(可以自定义)
  • ip port : IP地址和端口号
  • quorun:票数,Sentinel需要协商同意master是否可到达的数量。

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)。
票数在本文中:redis集群中有3个sentinel实例,其中master挂掉啦,这里设置票数为2,表示有2个sentinel认为master挂掉啦,才能被认为是正真的挂掉啦。

sentinel <选项的名字> <主服务器的名字> <选项的值>

  • down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。

如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

  • parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。

5.其他配置
新增Redis启动脚本:startRedisServer.bat

@echo off
redis-server.exe redis.windows.conf
@pause

新增Redis-Sentinel启动脚本:startRedisSentinel.bat

@echo off
redis-server.exe sentinel.conf --sentinel 
@pause

在配置启动startrRedis6379.cmd,其他同理!

@echo off
cd Redis6379
startRedisServer.bat

在配置启动startrRedisSentinel26379.cmd,其他同理!

@echo off
cd Redis6379
startRedisSentinel.bat
at

配置完如图:

  1. 启动Sentinel实例

哨兵启动命令 redis-server.exe sentinel.conf --sentinel

第一步:点击startRedis.cmd ,启动Redis集群

第二步:点击startRedisSentinel.cmd ,启动哨兵实例

查看Sentinel启动日志,看到```
生成哨兵ID(Sentinel ID),并自动识别主服务器和从服务器!

[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

查看主服务器6379(Master)信息:

F:\nosql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>

查看主服务器6380(Slave)信息:

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>

Redis-Sentinel高可用场景演示

场景1:主服务器master宕机

当主服务器master宕机,那么Sentinel会通过选举(算法)机制,从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候,会发送命令slaveofno one来取消选中的这个slave,使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master,并删除监听列表中出现故障的Master服务器。
(1)关闭掉 6379主服务器

127.0.0.1:6379> shutdown
not connected>


(2)查看观察选举新的master的过程和显示了failover的过程,整个日志信息还是比较完整的。最后选举了6381为主服务器!

[114252] 03 Mar 13:32:59.945 * +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 * +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381



(3)查看6381服务器信息,角色为主,从服务器6380!

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>

场景2:之前故障的6379 master重新启动

(1)启动6379服务,发现6379成为6381的从服务器!

F:\nosql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf

[116640] 03 Mar 13:59:25.753 * The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 * Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 * MASTER <-> SLAVE sync started

(2)查看6381服务器状态信息:原来的master自动切换成slave,不会自动恢复成master。

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>

场景3:从服务器Slave宕机和重启

(1)关闭6380从服务器:

127.0.0.1:6380> shutdown
not connected>

(2)Sentinel日志:

[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381

(3)查看住服务器6381状态信息:

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>

(4)启动从服务器6380

Connecting to MASTER 127.0.0.1:6381

(5)查看住服务器6381状态信息:6380又回来了!

role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>

Redis-sentinel相关知识

  1. 主观下线和客观下线
  2. 每个 Sentinel 都需要定期执行的任务
  3. 自动发现 Sentinel 和从服务器

可以参考 Redis 的 Sentinel 文档

Jedis客户端使用Sentinel

;

import java.util.HashSet;
import java.util.Set;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;

public class RedisManagerUtil {

	private static JedisSentinelPool pool = null;
	// 自带的哨兵模式 JedisSentinelPool, 并在一开始初始化连接池
	static {
		try {
			JedisPoolConfig config = new JedisPoolConfig();
			// 控制一个pool可分配多少个jedis实例,通过pool.getResource()来获取;
			// 如果赋值为-1,则表示不限制;如果pool已经分配了maxActive个jedis实例,则此时pool的状态为exhausted(耗尽)。
			config.setMaxTotal(Integer.valueOf(1000));
			// 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例。
			config.setMaxIdle(Integer.valueOf(20));
			// 表示当borrow(引入)一个jedis实例时,最大的等待时间,如果超过等待时间,则直接抛出JedisConnectionException;
			config.setMinEvictableIdleTimeMillis(Integer.valueOf(-1));
			// 在borrow一个jedis实例时,是否提前进行validate操作;如果为true,则得到的jedis实例均是可用的;
			config.setTestOnBorrow(Boolean.valueOf(true));

			// master名称和配置文件中配置的要一样
			String master = "mymaster";
			//setinel客户端提供了master自动发现功能
			Set<String> sentinels = new HashSet<String>();
			sentinels.add("127.0.0.1:26379");
			sentinels.add("127.0.0.1:26380");
			sentinels.add("127.0.0.1:26381");

			pool = new JedisSentinelPool(master, sentinels, config);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	/**
	 * 构建redis连接池
	 * 
	 * @return JedisPool
	 */
	public static JedisSentinelPool getPool() {
		return pool;
	}

	/**
	 * 返还到连接池
	 * 
	 * @param pool
	 * @param redis
	 */
	public static void returnResource(JedisSentinelPool pool, Jedis redis) {
		if (redis != null) {
			try {
				pool.returnResource(redis);
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
	}

	/**
	 * 测试redis线程池是否正常
	 * @param args
	 */
	public static void main(String[] args) {
		JedisSentinelPool pool = RedisPoolAPIManager.getPool();
		Jedis redis = pool.getResource();
		System.out.println("redis = " + redis);

		if(redis != null){
			returnResource(pool,redis);
		}
	}
}


总结

Redis-Sentinel是Redis官方推荐的高可用性(HA) 解决方案,Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器(复用),以及主服务器属下的从服务器,并在被监视的主服务器下线时,自动执行故障转移操作。

为了防止sentinel的单点故障,可以对sentinel进行集群化,创建多个sentinel。

如果你想使用本篇博文中配置的redis-Sentinel,可以在这里Redis-Sentinel下载!

参考博文

Redis学习笔记(四) Redis哨兵(sentinel)

基于Sentinel(哨兵)搭建实现Redis高可用集群

本系列文章:

第一篇:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】

第二篇:Redis高可用集群-哨兵模式搭建配置教程【Windows环境】

第三篇:Redis集群模式-主从复制搭建配置教程【Windows环境】


如果您觉得这篇博文对你有帮助,请点赞或者喜欢,让更多的人看到,谢谢!

如果帅气(美丽)、睿智(聪颖),和我一样简单善良的你看到本篇博文中存在问题,请指出,我虚心接受你让我成长的批评,谢谢阅读!
祝你今天开心愉快!


欢迎访问我的csdn博客和关注的个人微信公众号!

愿你我在人生的路上能都变成最好的自己,能够成为一个独挡一面的人。

不管做什么,只要坚持下去就会看到不一样!在路上,不卑不亢!

博客首页 : http://blog.csdn.net/u010648555

© 每天都在变得更好的阿飞

已标记关键词 清除标记
相关推荐
韦东山老师为啥要录升级版嵌入式视频?<br /><br /> 200x年左右,嵌入式Linux在全世界、在中国刚刚兴起。<br /> 我记得我2005年进入中兴时,全部门的人正在努力学习Linux。<br /> 在2008年,我写了一本书《嵌入式Linux应用开发完全手册》。<br /> 它的大概内容是:裸机、U-boot、Linux内核、Linux设备驱动。<br /> 那时还没有这样讲解整个系统的书,<br /> 芯片厂家Linux开发包也还不完善,从bootloader到内核,再到设备驱动都不完善。<br /> 有全系统开发能力的人也很少。<br /> 于是这书也就恰逢其时,变成了畅销书。<br /> 我也根据这个思路录制了视频:裸机、U-boot、Linux内核、Linux设备驱动。<br /> 收获些许名声,带领很多人进入Linux世界。<br /><br /><strong>11年过去了,嵌入式Linux世界发生了翻天覆地的变化</strong><br /><br /> ① 基本系统能用<br /><br /> 芯片厂家都会提供完整的U-boot、Linux内核、芯片上硬件资源的驱动。<br /> 方案厂家会做一些定制,比如加上某个WIFI模块,会添加这个WIFI模块的驱动。<br /> 你可以使用厂家的原始方案,或是使用/借鉴方案商的方案,做出一个“能用”的产品。<br /><br /> ② 基础驱动弱化;级驱动专业化<br /><br /> 基础的驱动,比如GPIO、UART、SPI、I2C、LCD、MMC等,有了太多的书籍、视频、示例代码,修修改改总是可以用的。<br /> 很多所谓的驱动工程师,实际上就是“调参工程师”。<br /> 我们群里有名的火哥,提出了一个概念:这些驱动就起一个“hardware enable”的作用。<br /> 级的驱动,比如USB、PCIE、HDMI、MIPI、GPU、WIFI、蓝牙、摄像头、声卡。<br /><br /> 体系非常复杂,很少有人能讲清楚,很多时候只是一笔带过。<br /> 配置一下应用层工具就了事,能用就成。<br /> 这些级驱动,工作中需要专门的人来负责,非常专业。<br /> 他们是某一块的专家,比如摄像头专家、音频专家。<br /><br /> ③ 项目为王<br /> 你到一个公司,目的是把产品做出来,会涉及APP到内核到驱动全流程。<br /> 中小公司玩不起华为中兴的配置,需要的是全面手。<br /> 大公司里,只负责很小很小一块的镙丝钉,位置也不太稳固啊。<br /> 所以,如果你不是立志成为某方面的专家,那就做一个全栈工程师吧。<br /><br /> ④ 调试很重要<br /> 都说代码是3分写7分调,各种调试调优技术,可以为你的升职加薪加一把火。<br /> 基于上述4点,我录制的全新视频将有这些特点:<br /> 1. 快速入门,<br /> 2. 实战项目,<br /> 3. 驱动大全,<br /> 4. 专题,<br /> 5. 授人以渔,<br /> 6. 要做任务<br /> 另外,我们会使用多款芯片同时录制,先讲通用的原理,再单独讲各个板子的操作。<br /> 这些芯片涵盖主流芯片公司的主流芯片,让你学习工作无缝对接。<br /><img src="https://img-bss.csdn.net/201911180753564269.jpg" alt="" /><br /><br /><br /><br /> 1.快速入门<br /> 入门讲究的是快速,入门之后再慢慢深入,<br /> 特别是对于急着找工作的学生,对于业余时间挑灯夜读的工作了的人,一定要快!<br /> 再从裸机、U-boot、内核、驱动这样的路线学习就不适合了,时间就拉得太长了。<br /> 搞不好学了后面忘了前面。<br /> 并且实际工作中并不需要你去弄懂U-boot,会用就行:U-boot比驱动还复杂。<br /><br /> 讲哪些内容?<br /><img src="https://img-bss.csdn.net/201911180754297078.png" alt="" /><br /><br /> 怎么讲呢?<br /><br /> 混着讲<br /> 比如先讲LED APP,知道APP怎么调用驱动,再讲LED硬件原理和裸机,最后讲驱动的编写。<br /> 这样可以快速掌握嵌入式Linux的整套开发流程,<br /> 不必像以前那样光学习裸机就花上1、2个月。<br /> 而里面的裸机课程,也会让你在掌握硬件操作的同时,把单片机也学会了。<br /><br /> 讲基础技能<br /><br /> 中断、休眠-唤醒、异步通知、阻塞、内存映射等等机制,会配合驱动和APP来讲解。<br /> 这些技能是嵌入式Linux开发的基础。<br /> 而这些驱动,只会涉及LED、按制、LCD等几个驱动。<br /> 掌握了这些输入、输出的驱动和对应的APP后,你已经具备基本的开发能力了。<br /><br /> 讲配置<br /> 我们从厂家、从方案公司基本上都可以拿到一套完整的开发环境,怎么去配置它?<br /> 需要懂shell和python等配置脚本。<br /><br /><br /> 效果效率优先<br /> 以前我都是现场写代码、现场写文档,字写得慢,降低了学习效率。<br /> 这次,效果与效率统一考虑,不再追求所有东西都现场写。<br /> 容易的地方可先写好代码文档,难的地方现场写。<br /><br /> 2.实战项目<br /> 会讲解这样的涉及linux网关/服务器相关项目(不限于,请多提建议):<br />  <img src="https://img-bss.csdn.net/201911180754541383.jpg" alt="" />            <br />       <br /> 定位为:快速掌握项目开发经验,丰满简历。<br /> 涉及的每一部分都会讲,比如如果涉及蓝牙,在这里只会讲怎么使用,让你能写出程序;如果要深入,可以看后面的蓝牙专题。<br /><br /> 3. 驱动大全<br /> 包括基础驱动、级驱动。<br /> 这些驱动都是独立成章,深入讲解。<br /> 虽然基础驱动弱化了,但是作为Linux系统开发人员,这是必备技能,并且从驱动去理解内核是一个好方法。<br /> 在讲解这些驱动时,会把驱动的运行环境,比如内核调度,进程线程等概念也讲出来,这样就可以搭建一个知识体系。<br /> 没有这些知识体系的话,对驱动的理解就太肤浅了,等于在Linux框架下写裸机,一叶障目,不见泰山。<br /> 定位为:工具、字典,用到再学习。<br /><br /> 4. 专题<br /> 想深入学习的任何内容,都可独立为专题。<br /> 比如U-boot专题、内核内存管理专题、systemtap调试专题。<br />
©️2020 CSDN 皮肤主题: 成长之路 设计师:Amelia_0503 返回首页