Provide Best Programming Tutorials

使用 Python 查看局域网内存活主机

概述 当我们的网络首次接入一些新的设备,而且这些设备不是像手机、电脑一类的有屏幕设备,如服务器、Nas、树莓派等硬件,我们想要通过网络连接控制,但是并不知道设备的 IP 地址,这时,我们就需要扫描网络找到我们目标硬件设备的 IP 地址。 常用的方法如进入路由器管理后台,我们就可以找到我们的设备 IP 地址,或者使用现成的软件,如 AdbancedIP Scanner 软件,也可以扫描网络实现我们想要的目标。但是,实际上我们真正需要的仅仅是要知道设备名和 IP 地址即可,无论登录路由器还是使用软件,都显得有点牛刀杀鸡的感觉,因此我们尝试使用 Python 编写一个查找内网存活在线主机IP地址的脚本。关键词 Python nmap 局域网 存活主机IP NMAP Nmap 是一款用于网络发现和安全审计的网络安全工具,可以检测目标主机是否在线、端口开放情况、侦测运行的服务类型及版本信息、侦测操作系统与设备类型等信息。 在使用之前,我们需要先安装 Nmap 软件。对于 WIndow 系统,可以登录 Nmap 官网下载页面 下载相应版本安装即可。 对于 MacOS 系统,可以使用 HomeBrew 安装,具体方法如下: brew update…

Continue Reading

消息队列:秒杀时如何处理每秒上万次的下单请求?

在课程一开始,我就带你了解了高并发系统设计的三个目标:性能、可用性和可扩展性,而 在提升系统性能方面,我们一直关注的是系统的查询性能。也用了很多的篇幅去讲解数据库 的分布式改造,各类缓存的原理和使用技巧。究其原因在于,我们遇到的大部分场景都是读 多写少,尤其是在一个系统的初级阶段。 比如说,一个社区的系统初期一定是只有少量的种子用户在生产内容,而大部分的用户都 在“围观”别人在说什么。此时,整体的流量比较小,而写流量可能只占整体流量的百分之 一,那么即使整体的 QPS 到了 10000 次 / 秒,写请求也只是到了每秒 100 次,如果要对 写请求做性能优化,它的性价比确实不太高。 但是,随着业务的发展,你可能会遇到一些存在高并发写请求的场景,其中秒杀抢购就是最 典型的场景。假设你的商城策划了一期秒杀活动,活动在第五天的 00:00 开始,仅限前 200 名,那么秒杀即将开始时,后台会显示用户正在疯狂地刷新 APP 或者浏览器来保证自 己能够尽量早的看到商品。 这时,你面对的依旧是读请求过高,那么应对的措施有哪些呢? 因为用户查询的是少量的商品数据,属于查询的热点数据,你可以采用缓存策略,将请求尽 量挡在上层的缓存中,能被静态化的数据,比如说商城里的图片和视频数据,尽量做到静态 化,这样就可以命中 CDN…

Continue Reading

Java类加载机制(全套)

Java类加载机制(全套) 概述 在开始正文之前,我们先看两张图 。Java平台的理解?Java最显著的特性?Java是解释执行? 先看一下java程序的执行流程图 再看一下jvm的大致物理结构图 本文是我在学习jvm类加载机制的时候对网上的一些资料的整理和总结。本文将研究一下问题: 什么是类加载?类的加载过程(生命周期)?类什么时候初始化?类初始化顺序?类加载器、反射、字节码等一系列问题。 一、类加载机制概念 Java虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的加载机制。* Class文件由类装载器装载后,在JVM中将形成一份描述Class结构的元信息对象,通过该元信息对象可以获知Class的结构信息:如构造函数,属性和方法等,Java允许用户借由这个Class相关的元信息对象间接调用Class对象的功能,这里就是我们经常能见到的Class类。 二、类加载过程 工作机制 类装载器就是寻找类的字节码文件,并构造出类在JVM内部表示的对象组件。在Java中,类装载器把一个类装入JVM中,要经过以下步骤: (1) 装载:查找和导入Class文件; (2) 链接:把类的二进制数据合并到JRE中; (a)校验:检查载入Class文件数据的正确性; (b)准备:给类的静态变量分配存储空间; (c)解析:将符号引用转成直接引用; (3) 初始化:对类的静态变量,静态代码块执行初始化操作 复制代码 Java程序可以动态扩展是由运行期动态加载和动态链接实现的;比如:如果编写一个使用接口的应用程序,可以等到运行时再指定其实际的实现(多态),解析过程有时候还可以在初始化之后执行;比如:动态绑定(多态) 如上图所示,加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类的加载过程必须按照这个顺序来按部就班地开始,而解析阶段则不一定,它在某些情况下可以在初始化阶段后再开始。 类的生命周期的每一个阶段通常都是互相交叉混合式进行的,通常会在一个阶段执行的过程中调用或激活另外一个阶段。 在我参考别人的资料的时候,发现都是先介绍的类的初始化这个过程,但是我觉得这样会造成一种误解什么事类的初始化,和它应该发生的时机。这里我就按照类的加载生命周期顺序介绍每一个过程了。 1. 装载(加载)…

Continue Reading

Mysql 底层数据结构

索引数据结构对比 二叉树 左边子节点的数据小于父节点数据,右边子节点的数据大于父节点数据。如果col2是索引,查找索引为89的行元素,那么只需要查找两次,就可以获取到行元素所在的磁盘指针地址。 如果col1是索引,查找索引为6的行元素,那么需要查找六次,就可以获取到行元素所在的磁盘指针地址,即得到了该索引为6的行元素。因此二叉树不适合存储单边增长的序列字段,近乎全表扫描获取数据。 红黑树 本质二叉树,属于二叉平衡树,jdk1.8 hashmap的底层实现;存储大数据量,树的高度不可控, 数量越大,树的高度越高;500w行数据,2的n次方=500w数据量, n是树的高度,也就是查询次数; hash表 通过散列可以快速获取磁盘文件指针,对于指定索引查找文件非常快,但是对于范围查找没法支持。 B树 本质是多路二叉树;叶节点具有相同的深度,叶节点的指针为空;所有索引元素不重复;节点中数据索引从左到右依次递增的; B+树(B树的变种) 非叶子节点不存储数据,只存储索引(冗余)和指针,可以放更多的索引,树高降低 ;叶子节点包含所有索引字段;叶子节点比b树增加了指针连接;叶子节点有双向指针链接(首尾子节点还通过指针连接),提高区间访问的性能,范围查找; 为什么mysql页文件默认16K? MySQL每个B+树节点最大存储容量:16KB (指针+数据+索引)。假设我们一行数据大小为1K,那么一页就能存16条数据,也就是一个叶子节点能存16条数据;再看非叶子节点,假设主键ID为bigint类型,那么长度为8B,指针大小在Innodb源码中为6B,一共就是14B,那么一页里就可以存储16K/14=1170个(主键+指针)那么一颗高度为2的B+树能存储的数据为:117016=18720条,一颗高度为3的B+树能存储的数据为:11701170*16=21902400(千万级条) show global status like `Innodb_page_size`复制代码 因此,B+树存储大数据量的表也可以非常高效的获取数据,MySQL使用B+树作为索引的数据结构。 存储引擎 存储引擎最终作用于:表 ,不是数据库在mysql的安装的根目录下,有一个data目录,里面存放的是所有表的数据。 MyISAM:MyISAM索引文件和数据文件是分离的(非聚集或稀疏);主键索引和辅助主键索引存储类似; frm文件:存储这张表的表结构MYD文件:存储这张表的所有数据行MYI文件:存储这张表的索引字段…

Continue Reading

TCC事务机制简介

关于TCC(Try-Confirm-Cancel)的概念,最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中,TCC还是以Tentative-Confirmation-Cancellation作为名称;正式以Try-Confirm-Cancel作为名称的,可能是Atomikos(Gregor Hohpe所著书籍《Enterprise Integration Patterns》中收录了关于TCC的介绍,提到了Atomikos的Try-Confirm-Cancel,并认为二者是相似的概念)。 国内最早关于TCC的报道,应该是InfoQ上对阿里程立博士的一篇采访。经过程博士的这一次传道之后,TCC在国内逐渐被大家广为了解并接受。相应的实现方案和开源框架也先后被发布出来,ByteTCC就是其中之一。 TCC事务机制相对于传统事务机制(X/Open XA Two-Phase-Commit),其特征在于它不依赖资源管理器(RM)对XA的支持,而是通过对(由业务系统提供的)业务逻辑的调度来实现分布式事务。 对于业务系统中一个特定的业务逻辑S,其对外提供服务时,必须接受一些不确定性,即对业务逻辑执行的一次调用仅是一个临时性操作,调用它的消费方服务M保留了后续的取消权。如果M认为全局事务应该rollback,它会要求取消之前的临时性操作,这将对应S的一个取消操作;而当M认为全局事务应该commit时,它会放弃之前临时性操作的取消权,这对应S的一个确认操作。 每一个初步操作,最终都会被确认或取消。因此,针对一个具体的业务服务,TCC事务机制需要业务系统提供三段业务逻辑:初步操作Try、确认操作Confirm、取消操作Cancel。 1. 初步操作(Try)TCC事务机制中的业务逻辑(Try),从执行阶段来看,与传统事务机制中业务逻辑相同。但从业务角度来看,却不一样。TCC机制中的Try仅是一个初步操作,它和后续的确认一起才能真正构成一个完整的业务逻辑。可以认为 1[传统事务机制]的业务逻辑 = [TCC事务机制]的初步操作(Try) + [TCC事务机制]的确认逻辑(Confirm)。 TCC机制将传统事务机制中的业务逻辑一分为二,拆分后保留的部分即为初步操作(Try);而分离出的部分即为确认操作(Confirm),被延迟到事务提交阶段执行。TCC事务机制以初步操作(Try)为中心的,确认操作(Confirm)和取消操作(Cancel)都是围绕初步操作(Try)而展开。因此,Try阶段中的操作,其保障性是最好的,即使失败,仍然有取消操作(Cancel)可以将其不良影响进行回撤。 2. 确认操作(Confirm)确认操作(Confirm)是对初步操作(Try)的一个补充。当TCC事务管理器决定commit全局事务时,就会逐个执行初步操作(Try)指定的确认操作(Confirm),将初步操作(Try)未完成的事项最终完成。 3. 取消操作(Cancel)取消操作(Cancel)是对初步操作(Try)的一个回撤。当TCC事务管理器决定rollback全局事务时,就会逐个执行初步操作(Try)指定的取消操作(Cancel),将初步操作(Try)已完成的事项全部撤回。 在传统事务机制中,业务逻辑的执行和事务的处理,是在不同的阶段由不同的部件来完成的:业务逻辑部分访问资源实现数据存储,其处理是由业务系统负责;事务处理部分通过协调资源管理器以实现事务管理,其处理由事务管理器来负责。二者没有太多交互的地方,所以,传统事务管理器的事务处理逻辑,仅需要着眼于事务完成(commit/rollback)阶段,而不必关注业务执行阶段。 而在TCC事务机制中的业务逻辑处理和事务处理,其关系就错综复杂:业务逻辑(Try/Confirm/Cancel)阶段涉及所参与资源事务的commit/rollback;全局事务commit/rollback时又涉及到业务逻辑(Try/Confirm/Cancel)的执行。其中关系,本站将另行撰文详细介绍,敬请关注!

Continue Reading

常用的分布式事务解决方案

什么是事务? 事务由一组操作构成,我们希望这组操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。 事务的四大特性 ACID 说到事务,就不得不提一下事务著名的四大特性。 原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。 一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果仍然不会丢失。 注意:事务只能保证数据库的高可靠性,即数据库本身发生问题后,事务提交后的数据仍然能恢复;而如果不是数据库本身的故障,如硬盘损坏了,那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此,事务只能保证数据库的『高可靠性』,而『高可用性』需要整个系统共同配合实现。 事务的隔离级别 这里扩展一下,对事务的隔离性做一个详细的解释。 在事务的四大特性ACID中,要求的隔离性是一种严格意义上的隔离,也就是多个事务是串行执行的,彼此之间不会受到任何干扰。这确实能够完全保证数据的安全性,但在实际业务系统中,这种方式性能不高。因此,数据库定义了四种隔离级别,隔离级别和数据库的性能是呈反比的,隔离级别越低,数据库性能越高,而隔离级别越高,数据库性能越差。 事务并发执行会出现的问题 我们先来看一下在不同的隔离级别下,数据库可能会出现的问题: 更新丢失 当有两个并发执行的事务,更新同一行数据,那么有可能一个事务会把另一个事务的更新覆盖掉。 当数据库没有加任何锁操作的情况下会发生。 脏读 一个事务读到另一个尚未提交的事务中的数据。 该数据可能会被回滚从而失效。 如果第一个事务拿着失效的数据去处理那就发生错误了。 不可重复读 不可重复度的含义:一个事务对同一行数据读了两次,却得到了不同的结果。它具体分为如下两种情况: 虚读:在事务1两次读取同一记录的过程中,事务2对该记录进行了修改,从而事务1第二次读到了不一样的记录。幻读:事务1在两次查询的过程中,事务2对该表进行了插入、删除操作,从而事务1第二次查询的结果发生了变化。 不可重复读…

Continue Reading

maven-wrapper介绍

环境依赖 JAVA_HOME 环境变量需要配置 maven-wrapper的应用 使用https://start.spring.io/生成Spring Boot初始项目时,发现其中有几个奇怪的文件 ├── .mvn │ └── wrapper │ ├── maven-wrapper.jar │ └── maven-wrapper.properties ├── mvnw └── mvnw.cmd 复制代码 maven-wrapper干嘛用的? 先来看看传统maven的使用流程 传统使用maven需要先到官网上下载配置环境变量把mvn可执行文件路径加入到环境变量,以便之后使用直接使用mvn命令。另外项目pom.xml文件描述的依赖文件默认是下载在用户目录下的.m2文件下的repository目录下。再次,如果需要更换maven的版本,需要重新下载maven并替换环境变量path中的maven路径。 现在有了maven-wrapper,会获得以下特性 执行mvnw比如mvnw clean ,如果本地没有匹配的maven版本,直接会去下载maven,放在用户目录下的.m2/wrapper中并且项目的依赖的jar包会直接放在项目目录下的repository目录,这样可以很清晰看到当前项目的依赖文件。如果需要更换maven的版本,只需要更改项目当前目录下.mvn/wrapper/maven-wrapper.properties的distributionUrl属性值,更换对应版本的maven下载地址。mvnw命令就会自动重新下载maven。可以说带有mvnw文件的项目,除了额外需要配置 java环境外,只需要使用本项目的mvnw脚本就可以完成编译,打包,发布等一系列操作。 在项目初始化mvnw文件 如果你的项目没有mvnw文件,需要先下载maven,并把mvn可执行文件路径需加入的PATH中。然后执行以下命令,就会自动生成mvnw相关一系列文件…

Continue Reading

使用Beyond Compare作为git mergetool的默认对比工具 For Mac

第一步 点击下载下载Beyond Compare 第二步 image.png 第三步 Mac上需要在user目录下的.gitconfig文件中加入下面的配置: 或用终端打开.gitconfig文件在里面添加下面的配置, 终端指令 $git config --edit --global [diff] tool = bcomp [difftool "bcomp"] cmd = \"/usr/local/bin/bcomp\" \"$LOCAL\" \"$REMOTE\" [difftool] prompt = false [merge] tool…

Continue Reading
Close Menu