zookeeper理解

Zookeeper简介

Zookeeper的数据模型

  • 层次化的目录结构，命名符合常规文件系统规范
  • 每个节点在zookeeper中叫做znode，并且有一个唯一的路径标识
  • 节点znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
  • Znode中的互刷可以有多个版本，比如某一个路径下存在多个数据版本，那么查询这个路径下的数据就需要带上版本号
  • 客户端应用可以在节点上设置监视器
  • 节点不支持部分读写，而是一次性完整读写

Zookeeper的节点

  • Znode有两种类型，短暂的（ephemeral）和持久节点（persistent）
  • Znode的类型在创建时确定并且不能修改
  • 短暂的Znode的客户端会话结束，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
  • 持久Znode不依赖客户端会话，只有当客户端明确要删除改Znode时候才会被删掉
  • Znode有四种形式的目录节点：
    • persistent 是永久节点
    • persistent_sequential 是永久有序节点
    • ephemeral 是临时节点
    • ephemeral_sequential 是临时有序节点

Zookeeper的角色

  • 领导者（leader），负责进行投票和发起决议，更新系统状态
  • 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接收客户端请求并向客户端返回结果，在选主过程中参与投票
  • 观察者（Observer），可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。
  • 客户端（client），请求发起方：
    在这里插入图片描述

Zookeeper的顺序号

  • 创建Znode时设置顺序标识，znode名称后面会附加一个值
  • 顺序号是一个单递增的计数器，由父节点维护
  • 在分布式系统中，顺序号可以被用于所有事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

Zookeeper的读写机制

  • zookeeper是一个由多个server组成的集群
  • 一个leader，多个follower
  • 每个server保存一份数据副本
  • 全局数据一致
  • 分布式读写
  • 更新请求转发由leader实施

Zookeeper的保证

  • 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
  • 数据更新原子性，依次数据更新要么成功，要么失败
  • 全局唯一数据视图，client无论链接到哪个server，数据视图都是一致的
  • 实时性，在一定事件范围内，client能督导的最新数据

Zookeeper的api接口

  • String create（String path，byte[] data, List acl, CreateMode createMode）:
    • 创建一个给定目录节点的path，并给他设置数据，CreateMode标识有四种形式目录，分别是：
    • PERSISTENT：持久化目录节点，这个目录节点存储的数据不会丢失；
    • PERSISTEN_SEQUENTIAL：顺序自动编号的目录节点，这种节点会根据当前已经存在的节点数自动加1，然后返回给客户端已经成功创建的目录节点名
    • EPHEMERAL：临时目录节点，一旦创建这个节点的客户端与服务器断开，也就是session超时，这种节点会被自动删除
    • EPHEMERAL_SEQUENTIAL：临时自动编号节点
  • Stat exists（String path， boolean watch）：
    • 判断某个path是否存在，并设置是否监控这个目录节点，这里的watcher是在创建zookeeper实例时指定的watcher，exists方法还有一个重载方法，可以执行特定的watcher
  • Stat exists（String path， Watcher watcher）
    • 重载方法，这里给某个目录节点设置特定的watcher，watcher在zookeeper是一个核心功能，watcher可以监控目录加点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的watcher，从而每个客户端都很快知道他所关注的节点的状态发生变化，而做出相应的反应
      …

观察（watcher）

  • watcher在Zookeeper中是一个核心功能，watcher可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的 Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，从而做出相应反应（一个节点可以设置多个watcher，也就是每个客户端都可以在一个节点上设置观察）
  • 可以设置观察的操作：exists，getChildren， getData
  • 可以触发观察操作：create， delete，setData

写操作与zookeeper内部事件的对应关系

在这里插入图片描述

写操作与watcher的对应关系

在这里插入图片描述

每个znode被创建时候都会带有一个ACL列表，用于决定谁可以对他执行何种操作

在这里插入图片描述

ACL访问控制列表（Access Control List， ACL）

  • 身份验证模式有三种：
    • digest：用户名密码
    • host：通过客户端的主机名来识别客户端
    • ip：通过客户端的ip来识别客户端
  • new ACL（Perms.READ， new Id(“host”, “example.com”)）; 这个ACL对应身份验证模式是host，符合改模式的身份是exmple.com，权限组合是：READ

Znode的节点状态

在这里插入图片描述

Zookeeper工作原理

  • zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫Zab协议。Zab协议有两种模式，他们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
  • 一旦leader已经和多数follower进行了状态同步后，他就可以开始广播消息，即进入广播状态。这时候，当一个server加入zookeeper服务中，他会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，他也参与消息广播。Zookeeper服务一直维持在broadcast状态，直到崩溃或者leader失去了大部分followers支持。
  • 广播模式需要保证proposal被按顺序处理，因此ZK采用了递增的事务id号码（zxid）来保证，所有的提议（proposal）都被踢出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，他都会有一个新的epoch，低32位是个递增计数
  • 当leader崩溃或者leader失去大多数follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有server都恢复到一个正确的状态。

Leader选举

  • 每个server启动以后都询问其他Server他要投票给谁
  • 对于其他server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）
  • 收到所有Server回复后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server
  • 计算这过程中获得票数最大的server为胜者，如果获胜者的票数超过半数，则该server被选为leader。否则，继续这个过程，知道leader被选出来
  • leader就会开始邓艾server链接
  • Follower链接leader将最大的zxid发送给leader
  • Leader根据fillower的zxid确定同步点
  • 完成同步后通知follow，已经成为uptodate状态
  • Follower收到uptodate消息后，又可以重新接受client的请求进行服务了
    在这里插入图片描述
    在这里插入图片描述

应用场景1-统一命名服务

  • 分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，即对人友好又不会重复。
  • Name Service是Zookeeper内置的功能，只要调用ZookeeperApi就能实现，如调用create接口就可以很容易创建一个目录节点从而得到一个全局唯一的path，这个path就可以作为一个名称。
  • 阿里的分布式服务框架Dubbo中使用Zookeeper来作其命名服务，维护全局的服务地址列表：
  1. 服务提供者在启动时候，想ZK上指定节点/dubbo/${serviceName}/providers 目录下写入自己的URL地址，这个操作就完成了服务的发布。
  2. 服务消费者启动的时候，订阅/dubbo/serviceName/providers目录下的提供者URL地址，并向/dubbo/{serviceName}/consumer目录下写入自己的URL地址
  3. 注意：所有想ZK注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化
  4. 另外Dubbo还有针对服务力度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息

应用场景2-配置管理

  • 配置管理在分布式应用环境中很常见，例如同一个应用系统需要多台PCServer运行，但是他们运行的应用系统的某些配置项是相同的，如果需要修改这些相同的配置，那么必须同时修改每台云溪这个应用系统的PCServer，这样就非常麻烦而且容易出错
  • 将配置信息保存在Zookeeper的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息变化，每台机器就会收到Zookeeper的通知，然后从Zookeeper获取新的配置信息应用到系统中。
    在这里插入图片描述

应用场景3-集群管理

  • Zookeeper能够很容易的实现集群管理的功能，如有多台Server组成一个服务器集群，那么必须要有一个总管知道当前集群中每一台服务器的服务状态，一旦有集群不能提供服务，集群中其他集群必须知道，从而做出调整重新分配服务策略。同当增加集群的服务能力时，就会增加一台或者多台Server，同样也需要让总管知道
  • Zookeeper不仅能维护当前集群中集群的服务状态，而且能够选出一个总管，让这个总管来管理集群，这就是Zookeeper的另一个功能Leader Election。
  • 他们的实现方式都是在Zookeeper上创建一个ephemeral类型的目录节点，然后每个Server在他们创建目录节点的父目录节点上调用getChildren（String Path，boolean watch）方法并设置watch为true，由于是Ephemeral目录节点，当创建他的Server死去，这个目录节点也随之被删除，所以Children将会变化，这时候getChildren上的watch将会被调用，所有其他Server就知道已经有某一台Server死去，新增加Server也是同样的道理。
  • Zookeeper如何实现Leader Election，也就是选出一个Master Server，和签名的一样每台Server 创建一个Ephemeral目录节点，不同的是他还是一个SEQUENTIAL目录节点，是一个有序的临时节点，我们可以选出当前最小编号的Server是Master，加入这个最小编号Server死去，由于是Ephemeral节点，死去的Server对应的节点也会被删掉，所以当前的节点列表中会出现另外一个最小编号节点，我们就选这个为当前Master，这就实现动态选择Master，避免了传统意义上单Master容易出现单节点故障问题。
    在这里插入图片描述
 zk.create("/testRootPath/testChildPath1","1".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create(“/testRootPath/testChildPath2”,“2”.getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create("/testRootPath/testChildPath3","3".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create("/testRootPath/testChildPath4","4".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);System.out.println(zk.getChildren("/testRootPath", false));
//输出[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]
  • 规定最小编号的为Master，所以我们水Servers节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出
  • 这个master宕机znode就删除，新列表推送新的列表，在选出最小编号master，这样就动态master选举
  • LeaderElection关键代码
 void findLeader() throws InterruptedException { byte[] leader = null; try { leader = zk.getData(root + "/leader", true, null); } catch (Exception e) { logger.error(e); } if (leader != null) { following(); } else { String newLeader = null; try { byte[] localhost = InetAddress.getLocalHost().getAddress(); newLeader = zk.create(root + "/leader", localhost, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); } catch (Exception e) { logger.error(e); } if (newLeader != null) { leading(); } else { mutex.wait(); } } }

应用场景4-共享锁

  • 共享锁在同一个进程中很容易实现，但是在跨JVM，不同Server之间就不好实现。Zookeeper却很容易实现这个功能，实现方式也是需要获得锁的Server创建一个EPHEMERAL_SEQUENTIAL目录节点（有序临时节点），然后调用getChildren方法获取当前目录节点列表最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么他就获得这个锁，如果不是那么它就调用exists（String path，boolean watch）方法并且监控Zookeeper生目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除签名它自己所创建的目录节点就行了
    在这里插入图片描述- 同步锁关键代码如下：
void getLock() throws KeeperException, InterruptedException{ List<String> list = zk.getChildren(root, false); String[] nodes = list.toArray(new String[list.size()]); Arrays.sort(nodes); if(myZnode.equals(root+"/"+nodes[0])){ doAction(); } else{ waitForLock(nodes[0]); } } void waitForLock(String lower) throws InterruptedException, KeeperException {Stat stat = zk.exists(root + "/" + lower,true); if(stat != null){ mutex.wait(); } else{ getLock(); } }

应用场景5-队列管理

  • Zookeeper可以处理两种类型的队列：
    • 当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到大，这种是同步队列
    • 队列按照FIFO方式进行入队和出队操作，例如，实现生产者消费者模型。
  • 创建一个父目录/synchronizing，每个成员都监控目录/synchronizing/start是否存在，然后每个成员都加入这个队列（创建/synchronizing/member_i的临时目录节点），然后每个成员获取/synchronizing目录的所有目录节点，判断i的值是否已经是成员的个数，如果小于成员的个数等待/synchronizing/start的出现，如果相等就创建/synchronizing/start
    在这里插入图片描述
  • 同步队列代码：
void addQueue() throws KeeperException, InterruptedException{ zk.exists(root + "/start",true); zk.create(root + "/" + name, new byte[0], Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); synchronized (mutex) { List<String> list = zk.getChildren(root, false); if (list.size() < size) { mutex.wait(); } else { zk.create(root + "/start", new byte[0], Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT); } } 
}
  • 当队列没有满进入wait，然后一直等待watch的通知，watch的代码如下
  public void process(WatchedEvent event) { if(event.getPath().equals(root + "/start") &&event.getType() == Event.EventType.NodeCreated){ System.out.println("得到通知"); super.process(event); doAction(); } }
  • FIFO队列用Zookeeper实现思路：
  • 在特定目录下创建SEQUENTIAL类型（有序类型）的目录/queue_i，这样就能保证所有成员入队列都有编号，出队了时通过getChildren方法可以返回当前所有的队列中的元素，然后消费其中最小的一个，这样就保证FIFO
  • 生产者代码：
boolean produce(int i) throws KeeperException, InterruptedException{ ByteBuffer b = ByteBuffer.allocate(4); byte[] value; b.putInt(i); value = b.array(); zk.create(root + "/element", value, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT_SEQUENTIAL); return true; 
}
  • 消费者代码
int consume() throws KeeperException, InterruptedException{ int retvalue = -1; Stat stat = null; while (true) { synchronized (mutex) { List<String> list = zk.getChildren(root, true); if (list.size() == 0) { mutex.wait(); } else { Integer min = new Integer(list.get(0).substring(7)); for(String s : list){ Integer tempValue = new Integer(s.substring(7)); if(tempValue < min) min = tempValue; } byte[] b = zk.getData(root + "/element" + min,false, stat); zk.delete(root + "/element" + min, 0); ByteBuffer buffer = ByteBuffer.wrap(b); retvalue = buffer.getInt(); return retvalue; } } } 
}

应用场景6-负载均衡

  • 这里的负载均衡是指的软负载均衡。分布式系统中，都是多服务集群部署。服务消费者需要在集群中选择一个来执行相关业务，就去比较经典的生产者消费者问题。
  • 消息中间件中发布者和订阅者的负载均衡，linkedin开源的kafkaMQ和阿里开源的metaq都是zookeeper来做负载均衡，这里以metaq为案例如下：
    • 生产者负载均衡：metaq发送消息时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此metaq在运行过程中会吧broker和对应的分区信息全部注册到ZK指定节点上，默认的策略是一个依次轮询的过程，生产者在通过ZK获取分区列表后，会按照brokerid和partition的顺序排列组织成一个有序的分区列表，发送的时候，按照从头到位循环往复的方式选择一个分区来发送消息。
    • 消费负载均衡：在消费过程中，一个消费者会消费一个或多个分区中的消息，但是一个分区只会由一个消费者来消费。MetaQ的消费策略是:
    • 每个分区针对同一个group只挂载一个消费者
    • 如果同一个group的消费者数目大于分区数目，则有部分消费者需要额外承担消费任务
    • 如果同一个group的消费者数目小于分区数目，则又部分消费者需要额外承担消费任务。
    • 在某个消费者故障或者重启等情况下，其他消费者会感知到这一个变化（通过Zookeeper watch 消费者列表），然后重新进行负载均衡，保证所有分区都有消费者进行消费。

总结

  • Zookeeper作为Hadoop项目中子项目，是Hadoop集群管理一个必不可少的模块，主要用来控制集群中数量，如他管理Hadoop集群中NameNode，还有Hbase中Master Election，Server之间状态同步等。
  • Zookeeper提供了一套很好的分布式集群管理机制，就是他这种基于层次型的目录树的数据结构，并对树中节点进行有效管理，从而可以设计出多种多样的分布式数据管理模型。

下一篇Zookeeper理解—ZAB协议

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/310621.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

那些年，在MSRA实习过的女孩，现在都怎么样了？

那些年，在MSRA实习过的女孩，现在都怎么样了？

编者按&#xff1a;我们用两周时间回访了五位在 MSRA 实习过的女孩&#xff0c;她们也都是当年“实习派”的主人公。我们本想在更长的时间维度下&#xff0c;看一看 MSRA 给予她们的改变。然而超乎预期的是&#xff0c;在她们身上&#xff0c;坚持的力量比改变更强。变与不变&a…
阅读更多...
Zookeeper理解---ZAB协议

Zookeeper理解---ZAB协议

ZAB协议 Zookeeper并不是完全采用Paxos算法&#xff0c;而是使用了一种称为Zookeeper Atomic Broadcast&#xff08;ZAB&#xff0c;Zookeeper原子消息广播协议&#xff09;作为数据一致性的核心算法&#xff0c;依据此算法来实现分布式数据一致性的解决。他是一种特别为Zooke…
阅读更多...
【最强VSCode】之管理MySql数据库

【最强VSCode】之管理MySql数据库

(梅花香自苦寒来)你没有看错&#xff0c;就是用VSCode来管理MySql数据库&#xff0c;我也是第一次听说&#xff0c;感谢群管理DX小伙伴&#xff0c;三人行必有我师焉。话不多说&#xff0c;直接开张&#xff0c;VSCode还是很不错的&#xff0c;以后多多分享插件吧。1、你平时是…
阅读更多...
[Flags]标识的Enum不能使用Html.GetEnumSelectList方法

[Flags]标识的Enum不能使用Html.GetEnumSelectList方法

在使用Asp.Net Core MVC写程序时&#xff0c;对用户类型做了如下定义&#xff1a;namespace ManufacturingExecutionSystemCore.Enums {public enum UserType{[Description("无身份人员")][Display(Name "无身份人员")]UnidentifiedPerson0x00,[Descripti…
阅读更多...
Zookeeper实践与应用- Canal

Zookeeper实践与应用- Canal

基于MySql BinLog的增量订阅和消费组件&#xff1a;Canal Cancal是阿里13年1月开源的一个基于MySql数据库Binlog实现的增量订阅和消费的组件。项目取名Canal取自管道的英文单词&#xff0c;流转的医生&#xff0c;是一个定位于基于MySql数据库Binlog增量日志来实现数据库镜像&…
阅读更多...
你遇到的面试官是「伯乐」吗？

你遇到的面试官是「伯乐」吗？

之前写了一篇应应聘者视角的「面试中要注意的点」&#xff0c;《聊聊面试的事&#xff08;应聘方&#xff09;》。这次再来一篇面试官视角的。如果你不是面试官&#xff0c;也没关系。所谓“知己知彼&#xff0c;方能百战百胜”&#xff0c;了解一下面试官在面试时的侧重点&…
阅读更多...
记录一次线上超时异常查询

记录一次线上超时异常查询

线上事故复盘 前言 前一次上线&#xff0c;当时正常&#xff0c;第二天发现有部分超时报警&#xff0c;最终发现应为Dubbo接口一次传输数据量太大导致线程虚拟内存占用 线上问题排查过程 报警邮件中查询到有一部分接口超时量激增&#xff0c;查询定位到某个Dubbo接口&#x…
阅读更多...
没用过.gitignore还敢自称高级开发？

没用过.gitignore还敢自称高级开发？

Git是跟踪项目中所有文件的好工具&#xff0c; 但是&#xff0c;您会希望在项目的整个生命周期中不要跟踪某些文件及其变更。系统文件&#xff08;i.e. Mac系统的.Ds_Store&#xff09;应用程序配置文件&#xff08;i.e. app.config, .env&#xff09;构建组件&#xff08;i.e.…
阅读更多...
支付价格计算中精度问题之double，float

支付价格计算中精度问题之double，float

前言 前段时间开发新的微信小程序&#xff0c;借此机会将老掉牙的支付模块重构&#xff0c;并且支持现金支付&#xff08;之前都是虚拟币支付&#xff09;&#xff0c;在重构期间遇到计算上的一些精度问题&#xff0c;虽然数额影响非常小但是影响比较大&#xff0c;我觉得有必…
阅读更多...
.net core 集成 sentry 进行异常报警

.net core 集成 sentry 进行异常报警

.net core 集成 sentry 进行异常报警IntroSentry 是一个实时事件日志记录和汇集的平台。其专注于错误监控以及提取一切事后处理所需信息而不依赖于麻烦的用户反馈。它分为客户端和服务端&#xff0c;客户端(目前客户端有 C#, Python, PHP, JavaScript, Ruby等多种语言)就嵌入在…
阅读更多...
[Qt入门]QTableWidget控件创建

[Qt入门]QTableWidget控件创建

#include "widget.h" #include "ui_widget.h"Widget::Widget(QWidget *parent) :QWidget(parent),ui(new Ui::Widget) {ui->setupUi(this);//TableWidget控件//设置列数ui->tableWidget->setColumnCount(3);//设置水平表头ui->tableWidget->…
阅读更多...
Zookeeper--Watcher机制源码剖析一

Zookeeper--Watcher机制源码剖析一

Watcher-- 数据变更通知 我们知道Zookeeper提供来分布式数据的订阅/发布功能&#xff0c;一个典型的发布/订阅模型系统定义了一种一对多的订阅关系&#xff0c;能让多个订阅者同时监听某个主题对象&#xff0c;当这个被监听对象自身状态发生变化时候&#xff0c;会通知所有订阅…
阅读更多...
.NET Core 3.1 的REST 和gRPC 性能测试

.NET Core 3.1 的REST 和gRPC 性能测试

看到越南小哥 的github 上的Evaluating Performance of REST vs. gRPC &#xff0c; 使用的是.NET Core 3.0 , 今天我把它升级到.NET Core 3.1 同样做了一个测试&#xff0c;文章的结果和他的博客文章是一样的&#xff1a;https://dev.to/thangchung/performance-benchmark-grp…
阅读更多...
Zookeeper--Watcher机制源码剖析二

Zookeeper--Watcher机制源码剖析二

Watcher触发 我们从实际操作时候的表现来看Watcher的触发&#xff0c;比如Zookeeper中NodeDataChanged时间的触发是“Watcher监听的对应数据节点的数据内容发生变更”&#xff0c;需要修改节点数据那么必然和数据节点存储的位置DataTree有关系&#xff0c;我们从这里去寻找修改…
阅读更多...
吴军《硅谷来信》工作篇学习总结

吴军《硅谷来信》工作篇学习总结

【学习总结】| 作者 / Edison Zhou这是恰童鞋骚年的第215篇原创文章2018年在得到App上订阅了吴军老师的《硅谷来信》&#xff0c;从此每天的碎片时间就开始听吴军老师在大洋彼岸寄来的信件了。整个来信涵盖了职业发展、工作效率、业余生活等多个主题&#xff0c;从吴军老师的视…
阅读更多...
Zookeeper实践与应用-- Nginx负载均衡差异

Zookeeper实践与应用-- Nginx负载均衡差异

Nginx/ZooKeeper 负载均衡的差异 Nginx 是我们常见的反向代理服务器&#xff0c;也被广泛的用作负载均衡服务器ZooKeeper是分布式协调服务框架&#xff0c;有时也被用来做负载均衡 Nginx Nginx负载均衡配置非常简单&#xff0c;吧多个Web Server配置到nginx中&#xff0c;用…
阅读更多...
从对我的质疑说起，谈谈Linux下的文件删除

从对我的质疑说起，谈谈Linux下的文件删除

特特本来就是个刚毕业的小菜&#xff0c;很多知识都是靠着大家的指点才慢慢学会的。之前在一篇"纯属虚构"的文章 (鹅厂后台开发工程师的工作日常) 提到使用 rm 命令删除一个近 100 G 的 log 文件。很荣幸&#xff0c;这篇文章被一个大号转载了&#xff0c;获得了很不…
阅读更多...
Zookeeper实践与应用--分布式锁实现

Zookeeper实践与应用--分布式锁实现

分布式锁 分布式锁是控制分布式系统之间同步访问资源的一种方式&#xff0c;如果不同系统是同一个系统的不同主机之间共享一个或一组资源&#xff0c;那么访问这些资源的时候&#xff0c;往往需要通过一些呼哧手段来防止彼此之间的干扰保证统一性&#xff0c;因此需要分布式锁…
阅读更多...
关于 Blazor Server Side 的一些杂项, 感想

关于 Blazor Server Side 的一些杂项, 感想

在2016年, 本人就开始了一个内部项目, 其特点就是用C#构建DOM树, 然后把DOM同步到浏览器中显示. 并且在一些小工程中使用.3年下来, 效果很不错, 但因为是使用C#来构建控件树, 在没有特定语法的情况下, 代码风格不是那么好.典型的风格大概是这样的:这个模式挺好的, 有点嫌弃C#代…
阅读更多...
重现江湖！大数据高并发——架构师秘籍

重现江湖！大数据高并发——架构师秘籍

大数据高并发的话题屡见不鲜&#xff0c;各种应对的方式方法也四处可见。然而笔试面试中一问就懵&#xff0c;简直是高薪拦路虎。为什么呢&#xff1f;究其原因&#xff0c;还是思路不清晰&#xff0c;缺乏实操&#xff0c;所以一问就倒。作为专注.Net领域十几年的老司机&#…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023