安安 - 版本
type: channel
link: https://blog.90.vc/tag/%E7%89%88%E6%9C%AC/
items: 获取HeidiSQL保存的密码
items: Kafka的集群部署实践及运维相关
items: Kubernetes 内部组件工作原理

获取HeidiSQL保存的密码
type: item
date: 2020-05-09T05:40:00+00:00
description: 今天在使用一个数据库时一是半会想不起来数据库的密码了，后来想起来在客户端工具heidisql上有保存过密码，下面讲解如何获取heidisql保存的密码。HeidiSQL是一款开源的SQL管理工具，用于管理MYSQL,MSSQL 等数据库，很多管理工具都会把密码存在本地，HeidiSQL也是如此，但是只是经过非常简单的编码，解密的过程如下。使用的是版本是HeidiSQL_11.0_64_Portable,配置会存在软件目录下的portable_settings.txt中,如果是安装的版的话，HeidiSQL安装版会配置信息存在以下注册表中：HKEY_CURRENT_USER\Software\HeidiSQL\密码会保存在以下节点下面。HKEY_CURRENT_USER\Software\HeidiSQL\Servers打开portable_settings.txt可以看到配置文件中有以下这样的ip 密码之类这样的信息HeidiSQL配置文件节选:Servers\192.168.1.1\SessionCreated<|||>1<|||>2020-04-23 09:11:48 Servers\192.168.1.1\Host<|||>1<|||>192.168.1.1 Servers\192.168.1.1\WindowsAuth<|||>3<|||>0 Servers\192.168.1.1\CleartextPluginEnabled<|||>3<|||>0 Servers\192.168.1.1\User<|||>1<|||>root Servers\192.168.1.1\Password<|||>1<|||>6A6A6A9 Servers\192.168.1.1\LoginPrompt<|||>3<|||>0 Servers\192.168.1.1\Port<|||>1<|||>3306 Servers\192.168.1.1\NetType<|||>3<|||>0 Servers\192.168.1.1\Compressed<|||>3<|||>0 Servers\192.168.1.1\LocalTimeZone<|||>3<|||>0 Servers\192.168.1.1\QueryTimeout<|||>3<|||>30 Servers\192.168.1.1\KeepAlive<|||>3<|||>20 Servers\192.168.1.1\FullTableStatus<|||>3<|||>1 Servers\192.168.1.1\Databases<|||>1<|||> Servers\192.168.1.1\Library<|||>1<|||>libmysql-6.1.dll Servers\192.168.1.1\Comment<|||>1<|||> Servers\192.168.1.1\StartupScriptFilename<|||>1<|||> Servers\192.168.1.1\TreeBackground<|||>3<|||>536870911 Servers\192.168.1.1\SSHtunnelHost<|||>1<|||> Servers\192.168.1.1\SSHtunnelHostPort<|||>3<|||>22 Servers\192.168.1.1\SSHtunnelUser<|||>1<|||> Servers\192.168.1.1\SSHtunnelPassword<|||>1<|||>1 Servers\192.168.1.1\SSHtunnelTimeout<|||>3<|||>4 Servers\192.168.1.1\SSHtunnelPrivateKey<|||>1<|||> Servers\192.168.1.1\SSHtunnelPort<|||>3<|||>3307 Servers\192.168.1.1\SSL_Active<|||>3<|||>0 Servers\192.168.1.1\SSL_Key<|||>1<|||> Servers\192.168.1.1\SSL_Cert<|||>1<|||> Servers\192.168.1.1\SSL_CA<|||>1<|||> Servers\192.168.1.1\SSL_Cipher<|||>1<|||> Servers\192.168.1.1\ServerVersionFull<|||>1<|||>5.7.29 - MySQL Community Server (GPL) Servers\192.168.1.1\ConnectCount<|||>3<|||>7 Servers…

Kafka的集群部署实践及运维相关
type: item
date: 2020-04-02T15:55:00+00:00
description: 一、Kafka的生产集群部署1.1 方案背景假设每天集群需要承载10亿数据。一天24小时，晚上12点到凌晨8点几乎没多少数据。使用二八法则估计，也就是80%的数据（8亿）会在16个小时涌入，而且8亿的80%的数据（6.4亿）会在这16个小时的20%时间（3小时）涌入。QPS计算公式：640000000 ÷ (3x60x60) = 60000，也就是说高峰期的时候Kafka集群要扛住每秒6万的并发。磁盘空间计算，每天10亿数据，每条50kb，也就是46T的数据。保存2个副本（在上一篇中也提到过其实两个副本会比较好，因为follower需要去leader那里同步数据，同步数据的过程需要耗费网络，而且需要磁盘空间，但是这个需要根据实际情况考虑），46 2 = 92T，保留最近3天的数据。故需要 92 3 = 276T1.2 QPS方面部署Kafka，Hadoop，MySQL···等核心分布式系统，一般建议直接采用物理机，抛弃使用一些低配置的虚拟机的想法。高并发这个东西，不可能是说，你需要支撑6万QPS，你的集群就刚好把这6万并发卡的死死的。加入某一天出一些活动让数据量疯狂上涨，那整个集群就会垮掉。但是，假如说你只要支撑6w QPS，单台物理机本身就能扛住4~5万的并发。所以这时2台物理机绝对绝对够了。但是这里有一个问题，我们通常是建议，公司预算充足，尽量是让高峰QPS控制在集群能承载的总QPS的30%左右（也就是集群的处理能力是高峰期的3~4倍这个样子），所以我们搭建的kafka集群能承载的总QPS为20万~30万才是安全的。所以大体上来说，需要5~7台物理机来部署，基本上就很安全了，每台物理机要求吞吐量在每秒4~5万条数据就可以了，物理机的配置和性能也不需要特别高。1.3 磁盘方面1.3.1 磁盘数量需要5台物理机的情况，需要存储276T的数据，平均下来差不多一台56T的数据。这个具体看磁盘数和盘的大小1.3.2 SAS还是SSD现在我们需要考虑一个问题：是需要SSD固态硬盘，还是普通机械硬盘？SSD就是固态硬盘，比机械硬盘要快，那么到底是快在哪里呢？其实SSD的快主要是快在磁盘随机读写，就要对磁盘上的随机位置来读写的时候，SSD比机械硬盘要快。比如说MySQL这种就应该使用SSD了（MySQL需要随机读写）。比如说我们在规划和部署线上系统的MySQL集群的时候，一般来说必须用SSD，性能可以提高很多，这样MySQL可以承载的并发请求量也会高很多，而且SQL语句执行的性能也会提高很多。因为写磁盘的时候kafka是顺序写的。机械硬盘顺序写的性能机会跟内存读写的性能是差不多的，所以对于Kafka集群来说其实使用机械硬盘就可以了。如果是需要自己创业或者是在公司成本不足的情况下，经费是能够缩减就尽量缩减的。1.4 内存角度JVM非常怕出现full gc的情况。kafka自身的jvm是用不了过多堆内存的，因为kafka设计就是规避掉用jvm对象来保存数据，避免频繁full gc导致的问题，所以一般kafka自身的jvm堆内存，分配个10G左右就够了，剩下的内存全部留给os cache。那服务器需要多少内存呢。我们估算一下，大概有100个topic，所以要保证有100个topic的leader partition的数据在操作系统的内存里。100个topic，一个topic有5个partition。那么总共会有500个partition。每个partition的大小是1G（在上一篇中的日志分段存储中规定了.log文件不能超过1个G），我们有2个副本，也就是说要把100个topic的leader partition数据都驻留在内存里需要1000G的内存。我们现在有5台服务器，所以平均下来每天服务器需要200G的内存，但是其实partition的数据我们没必要所有的都要驻留在内存里面，只需要25%的数据在内存就行，200G * 0.25 = 50G就可以了（因为在集群中的生产者和消费者几乎也算是实时的，基本不会出现消息积压太多的情况）。所以一共需要60G（附带上刚刚的10G Kafka服务）的内存，故我们可以挑选64G内存的服务器也行，大不了partition的数据再少一点在内存，当然如果能够提供128G内存那就更好。1.5 CPU coreCPU规划，主要是看你的这个进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果你的线程特别多，但是CPU核很少，就会导致你的CPU负载很高，会导致整体工作线程执行的效率不太高，上一篇的Kafka的网络设计中讲过Kafka的Broker的模型。acceptor线程负责去接入客户端的连接请求，但是他接入了之后其实就会把连接分配给多个processor，默认是3个，但是一般生产环境建议大家还是多加几个，整体…

Kubernetes 内部组件工作原理
type: item
date: 2020-03-31T14:32:00+00:00
description: 翻译自:https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca原作者：Joe Beda (Dad of two. CTO of Heptio. Started Google Compute Engine, Kubernetes and Google Container Engine.)本篇文章讲述了Kubernetes内部组件的工作原理，及创建POD的流程。如果你是运维人员或者是Kubernetes的使用者，你可以不需要知道Kubernetes的内部工作原理，但是如果你想理解Kubernetes内部的工作原理，这篇文章非常适合你。读这篇文章的前提是，你已经大致了解并会运用Kubernetes。这篇文章不会去描述什么是Kubernetes及其组件（如：Pod, Node, Kubelet）。 本篇将讨论Kubernetes核心组件及这些核心组件是如何让Kubernetes 对"爵士乐即兴演奏"。通常将像Kubernetes这样的通用系统称为容器的 "管弦乐编排"。但是管弦乐编排，必须有一个预先计划的指挥家。因此，这并不是Kubernetes的一个好的描述。相反，Kubernetes更像是爵士乐即兴演奏，有一系列演员互相配合协调完成演奏。接下来，开始介绍每个核心组件的功能。然后将看一个典型的调度和启动一个Pod的流程。1. Datastore: EtcdEtcd是Kubernetes的存储状态的数据库。虽然Kubernetes系统中有重要的内存缓存，但Etcd被认为是记录系统状态。Etcd的快速总结：它是一个集群分布式数据库，它可以提供分布式数据的一致性。这类的系统（如Zookeeper, Consul）是在 Google开发的chubby系统之后形成的，这些系统也称为"锁服务器"，因为他们可以实现分布式锁。Etcd和chubby的数据模型是一个简单的层次化的Key，并存储了简单的非结构化value，这看起来像是一个文件系统。有意思的是，在Google, chubby 被频繁用于为实现访问本地文件和对象存储的功能的抽象文件接口。然而，分布式数据库的高度一致性，提供了数据的严格写入顺序并允许client原子性的对数据做更新操作。可靠的系统的状态管理是任何系统中非常困难的一件事情。在分布式系统中，它是更加困难的，因为它引入了一致性算法，如raft或paxos。通过使用etcd，Kubernetes可以专注系统的其他部分。Etcd的watch机制是Kubernetes工作的关键。系统允许client去执行轻量级的对于Key值变化事件的订阅。当要watch的数据发生变化时, client会立即得到通知。这可以用作分布式系统组件之间的协调机制。 一个组件一旦写入etcd，其他组件可以立即对该变化作出反应。Etcd的消息机制正好和PubSub消息队列机制相反。在许多消息队列系统系统中，topic不存储真正的用户数据，但发布到这些topic的消息含有丰富的数据。对于像Etcd这样的系统，Key（类似于主题）存储了真实的数据而消息（数据变化通知）不含独特的丰富消息。换句话说，对于消息队列来说，topic很简单，而像Etcd则正好相反。（译者认为此处概括的非常准确）2. Policy Layer: API ServerKubernetes的核心组件是API Server，它是Kubernetes系统和Etcd直接对话的唯一组件。实际上，etcd是API server的实现细节，理论上也可以用其他分布式存储系统来支持Kubernetes.API server是一个策略组件，提供对Etcd的过滤访问。它的作用本质上是相对通用的，目前正在被分解处理。因此，API Server也可以用于其他系统的控制平面。API server的主要货物是资源，通过暴露简单的REST API 向外提供服务。这些资源有一个标准结构可以实现一些扩展功能。无论如何，API Server，允许各类组件创建，读取，写入，更新，和监视资源。API Server的具体的功能：认证和授权。Kubernetes有一个可插拔的认证系统。有一些内置的用户认证机制和授权这些用户访问资源。此外，还有一些方法可用于向外部服务提供这些服务。这种可扩展性是Kubernetes构建的核心功能。API Server运行一组可以拒绝或修改请求的准入控制器。 这些允许策略被应用并设置默认值。 这是确保在API Server客户端仍在等待请求确认时进入系统的数据有效性的关键。 虽然这些准入控制器目前正在编译到API Server中，但目前正在进行的工作是使其成为另一种可扩展性机制。API Server 有助…