work

SOLID原则是一种编码的标准，为了避免不良设计，所有的软件开发人员都应该清楚这些原则。SOLID原则是由Robert C Martin推广并被广泛引用于面向对象编程中。正确使用这些规范将提升你的代码的可扩展性、逻辑性和可读性。 当开发人员按照不好的设计来开发软件时，代码将失去灵活性和健壮性。任何一点点小的修改都非常容易引起bug。因此，我们应该遵循SOLID原则。 首先我们需要花一些时间来了解SOLID原则，当你能够理解这些原则并正确使用时，你的代码质量将会得到大幅的提高。同时，它可以帮助你更好的理解一些优秀软件的设计。 为了理解SOLID原则，你必须清楚接口的用法，如果你还不理解接口的概念，建议你先读一读这篇 文章 。 下面我将用简单易懂的方式为你描述SOLID原则，希望能帮助你对这些原则有个初步的理解。 单一责任原则 一个类只能因为一个理由被修改。 A class should have one, and only one, reason to change. 一个类应该只为一个目标服务。并不是说每个类都只能有一个方法，但它们都应该与类的责任有直接关系。所有的方法和属性都应该努力做好同一类事情。当一个类具有多个目标或职责时，就应该创建一个新的类出来。 我们来看一下这段代码： public class OrdersReportService { public List

目录 部署ETCD集群 Etcd 解析 方法一 修改hosts文件 方法二 增加bind解析 下载和分发etcd二进制文件 创建etcd证书和私钥 创建etcd的启动文件 测试 ETCD 集群状态 --- 下面的操作依托于上一篇文章 部署前期准备工作 部署ETCD集群 这里使用的ETCD为三节点高可用集群，步骤如下 下载和分发etcd二进制文件 创建etcd集群各节点的x509证书，用于加密客户端(如kubectl)与etcd集群、etcd集群之间的数据流 创建etcd的system unit文件，配置服务参数 检查集群工作状态 注意: 没有特殊说明都在node01节点操作 Etcd 解析 本次使用etcd单独的域名解析 方法一 修改hosts文件 在所有机器上操作 ， /etc/hosts 文件最后增加下面内容，也可以替换成自己的IP 10.0.20.11 etcd01 etcd01.k8s.com 10.0.20.12 etcd02 etcd02.k8s.com 10.0.20.13 etcd03 etcd03.k8s.com 方法二 增加bind解析 如果使用的内网 DNS bind 做内网解析增加下面解析 etcd01 IN A 10.0.20.11 etcd02 IN A 10.0.20.12 etcd03 IN A 10.0.20.13 下载和分发etcd二进制文件

Necessary knowledge, which includes at least some experience with all of them: Angular 8+ Nodejs GraphQL (Apollo for Angular for example) Sass Git & Git Flow Shell scripting Continuous deployment (Not necessarily Jenkins, but something like CircleCI is acceptable) Webpack Typescript for NodeJS Babel (for being used alongside typescript and webpack in Nodejs) Read and write specifications and requirements in English Exciting Extras which would give you leverage: Conversational English Auth0 or similar (i.e. Authy) OAuth DevOps (Docker, Kubernetes, Swarm...) Serverless framework or Lambda

一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群)，演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群，每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集； Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点，端口矩阵编排如下： 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权，mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户：admin/Admin @01 ，具有集群及所有库的管理权限 应用账号：appuser/AppUser @01 ，具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权，而针对初始化安装的场景，Mongodb提供了 localhost-exception机制 ，

Windows线程分为两种：Worker线程、GUI线程 worker线程：是指完全不牵扯到图形用户界面（GUI）， 纯粹做运算的线程 。 GUI线程：负责建造窗口以及处理消息循环（拥有消息队列） 。任何一个特定窗口的消息总是被产生这一窗口的线程抓到并处理（线程收到消息后派发给不同的窗口函数处理）。 操作系统会监控计算机上的键盘和鼠标等输入设备，为每一个输入事件（由用户操作所引发，比如用户按了某个键）生成一个消息。根据事件发生时的情况（比如当前激活的窗体负责接收用户按键，而依据用户点击鼠标的坐标可以知道用户在哪个窗体区域内点击了鼠标），操作系统会确定出此消息应该发给哪个窗体对象。这些生成的消息会统一地先临时放置在一个“系统消息队列（system message queue）”中，然后，操作系统有一个专门的线程负责从这一队列中取出消息，根据消息的目标对象（就是窗体的句柄），将其移动到创建它的UI线程所对应的消息队列中。（操作系统在创建进程和线程时，都同时记录了大量的控制信息，比如通过进程控制块和句柄表可以查找到进程所创建的所有线程和引用的核心对象，因此，根据窗体句柄来确定此消息应属于哪个UI线程对于操作系统来说是很简单的一件事）。UI线程启动一个消息循环，每次从本线程所对应的消息队列中取出一条消息，然后根据消息所包容的信息，将其转发给特定的窗体对象，此窗体对象所对应的“窗体过程

分库、分表、表分区 来源场景：读写分离以后可分为一个主库 ( 主库负责写 ) 加上 N 多个从库 ( 从库负责读 ) ， 但是因为业务量的扩大，主库还是无法承受写入的压力，那么此时就可以考虑分库、分表、表分区 来进一步优化 分库： 场景 1 ：比如一个系统涵盖了订单 \ 物流 \ 仓储 ..... 等等 垂直分库，按业务拆分库，不同库不同的服务器 场景 2：订单增删改特别大 水平分库，每个库结构一致数据不一致 (地域/时间/类别/随机算法) 分表 场景 1 ： 文章表， 10个常规字段+1个很长的内容字段 垂直分表，减小表体积，提升增删改查的效率 场景 2： 单表数据量太大 (订单表/商品表) 水平分表 (地域/时间/类别/随机算法) 表分区 一般情况下，我们建立数据库表时，表数据都存放在一个文件里。 但是如果是分区表的话，表数据就会按照你指定的规则分放到不同的文件里，把一个大的数据文件拆分为多个小文件，还可以把这些小文件放在不同的磁盘下由多个 cpu进行处理。这样文件的大小随着拆分而减小，还得到硬件系统的加强，自然对我们操作数据是大大有利的。 所以大数据量的数据表，对分区的需要还是必要的，因为它可以提高 select效率，还可以对历史数据经行区分存档等。但是数据量少的数据就不要凑这个热闹啦，因为表分区会对数据库产生不必要的开销，除啦性能还会增加实现对象的管理费用和复杂性。

Firewalld字符管理工具 1、Firewalld防火墙维护命令 1、防火墙进程操作 systemctl start firewalld [root@localhost ~] # systemctl start firewalld 设置 firewalld 为开机自启动 systemctl status firewalld [root@localhost ~] # systemctl enable firewalld 如果 firewalld 正在运行，通过 systemctl status firewalld 或 firewall-cmd 命令 可以查看其运行状态 systemctl restart firewalld [root@localhost ~] # systemctl status firewalld 关闭防火墙： systemctl stop firewalld 2、防火墙管理操作 irewall-cmd命令 支持全部防火墙特性 对于状态和查询模式，命令只返回状态，没有其他输出 –permanent参数：携带该参数表示永久配置，否则表示运行时配置 [–zone=] 选项：不携带此选项表示针对默认区域操作，否则针对指定区域操作 防火墙重载配置命令 1、firewall-cmd - --–reload [root@localhost ~]# firewall-cmd

背景 在项目开发过程中，我们经常需要执行具有周期性的任务。通过定时任务可以很好的帮助我们实现。 我们拿常用的几种定时任务框架做一个比较： 从以上表格可以看出，Spring Schedule框架功能完善，简单易用。对于中小型项目需求，Spring Schedule是完全可以胜任的。 1、springboot集成schedule 1.1 添加maven依赖包 由于Spring Schedule包含在spring-boot-starter基础模块中了，所有不需要增加额外的依赖。 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> 　　 1.2 启动类，添加启动注解 在springboot入口或者配置类中增加@EnableScheduling注解即可启用定时任务。

Proof Of Work 工作量证明 https://www.cnblogs.com/zhang-qc/p/10451817.html 借鉴了 哈希现金（Hashcash）-1997年 英国密码学专家亚当.贝克（Adam Back） 用工作量证明系统解决了 互联网垃圾邮件问题 ，它要求计算机在获得发送信息权限之前做一定的计算工作，这对正常的信息传播来讲，几乎很难察觉，但是对向全网大量散步垃圾信息的计算机来说，就成为了巨大的工作量和负担。 通过进行一定的运算和消耗一定的时间来计算一个符合规则的值，并提供给服务方快速做验证。 比特币中的POW共识 比特币 - 去中心化的点对点电子交易系统 ：维护分布式去中心化的账本 分布式无信任条件下的账本一致 ---》 共识 POW解决的是 拜占庭下的共识 ，保证分布式账本的最终一致性，解决双花攻击；同时也建立和维护了一个分布式的时钟 PoW系统的主要特征是 计算的不对称性 。（SHA256） 工作端需要做一定难度的工作得出一个结果，验证方却很容易通过结果来检查工作端是不是做了相应的工作。 作弊行为的前提在于花费大量的资源，一旦某人无法成功达成恶意目标就意味着其付出了巨大的且不可挽回的沉没成本。（这也是pow的优势所在，作恶有代价） 核心技术 ：散列函数 SHA256 比特币节点pow大致流程： 生成coinbase交易

1.问题闪现: yunduo@YunDuo:~/Work/Learning/Docker/docker_compose$ docker-compose up -d myshop_tomcat is up-to-date Starting myshop_mysql ... myshop_redis is up-to-date Starting myshop_mysql ... error ERROR: for myshop_mysql Cannot start service mysql: driver failed programming external connectivity on endpoint myshop_mysql (c42794af6a45ae1f176660abcd493c6c6345ddaec5c30ac84761e75cd3848484): Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use ERROR: for mysql Cannot start service mysql: driver failed programming external connectivity on endpoint myshop_mysql