Node.js Step 的使用

## 解决的问题 在Node.js中,绝大多数实际业务操作都是异步调用,比如文件IO,数据库操作,网络IO等等…… 当这些“耗时”操作完成后,会调用特定的操作,进行后续处理(这个后续的操作被称作callback 函数,作为之前的异步操作调用的最后一个参数)。 如果一个后台调用包含如下步骤: 1. 读取数据库,成功后, 2. 调用ERP接口,下生产订单,成功后, 3. 发送Email通知,成功后, 4. 写入数据库 这样的话,第一个调用的最后一个参数是步骤2对应的callback方法,这个方法再调用步骤3方法、再调用步骤4方法…… 整个效果,就是代码缩进后,越来越往右偏。Step就是为了解决这个问题,以一种“非嵌套”的方式,实现之前的这种调用结构。 ## 如何使用 step 库对外提供唯一的函数——Step。这个函数接受多个函数作为输入参数,这些参数对应的函数,其callback函数(*最后一个参数*)如果是 _this_,Step就会把下一个参数对应的函数,作为前一个函数调用的callback方法。 Step ( function readSelf() { fs.readFile(__filename, this); }, function capitalize(err, text) { if (err) throw err; return text.toUpperCase(); }, function showIt(err, newText) { if (err) throw err; console.log(newText); } ); 上例,第一个参数readSelf,包含一个异步调用readFile,我们在该传入callback 函数的位置,传入this。这就保证在异步操作完成后(readFile结束),Step会将读取的文件内容传递到下一个参数对应的函数(这个函数的格式像是普通的callback函数,第一个参数是err,第二个参数表示操作成功后获取的data)。本例中,第二个参数内执行的是“同步”操作,只需要直接return 结果。Step 会将结果,传递到下一个参数对应的函数showIt。

Linux 工具介绍:pidstat

# Linux工具介绍: pidstat 相较于传统、老旧的top,ps命令,pidstat能解决那些问题? 查看指定进程的stats 查看指定进程的磁盘操作(读、写)stats 查看指定进程所有线程(threads)的stats 查看每一个活动进程的CPU stats报告 获取: 进程触发了多少次 Context Switches (cs) 获取: 指定进程的内存使用、page faults 确认指定进程有无内存泄露 由上可知,pidstat提供了很多新能力,象查看进程的IO读写、内存使用等等,在分析诊断问题的时候都是关键的判断因素。 安装  不是最基础的Unix工具集成员,需要单独安装,属于 sysstat 包 ~ yum install sysstat ~ 用法: 查看指定进程的I/O stats ~ # pidstat -d -p interval count ~ ~ # pidstat -d -p 6417 2 10 ~ 6417 是我系统中OpenShift的进程ID, 2表示间隔2秒,10 表示采样10次,下面的输出显示,虽然这个进程是我系统中最消耗CPU的,但是并没有什么I/O操作。 _ ccwr: canceled writes

Linux 扩展ROOT文件系统

  Step 1: 确认磁盘分区使用 df -h Step 2: 格式化磁盘为LVM分区 fdisk /dev/sdb # 主分区 # 修改分区的系统类型为8e(Linux LVM) # 保存修改 Step 3: 创建pv(物理卷) pvcreate /dev/sdb1  pvdisplay  Step 4: 将新创建的pv添加到vg中 显示系统中已有vg vgdisplay  添加pv vgextend /dev/name-of-volume-group /dev/sdb1  Step 5: 修改root lv的大小,以占用所有分配空间 lvextend -l 100%FREE /dev/name-of-volume-group/root  确认修改 lvdisplay  Step 6: 应用修改到filesystem 查看 df -h  扩展文件系统 ext4 filesystem resize2fs /dev/name-of-volume-group/root  xfs

Aix平台查看进程打开的文件

最近刚好处理了一个Oracle数据库因为file descriptor耗尽,不能继续工作的案例。Oracle的MNL进程,打开了太多的文件,导致了这个错误。 背景: Unix中一切皆文件,socket,file… /proc 虚拟文件系统可以方便查看进程信息,包括打开的文件(fd,file descriptor) 大多数linux系统可以使用lsof来查看、使用/proc中包含的信息 Aix环境查看进程打开的文件 进入/proc/<mnl_process_pid>目录,查看fd子目录,可以查看所有打开的fd(file descriptor) # cd /proc/184422/fd# ls -l 这个文件夹下都是一些数字(fd),接下来使用相关工具,找到打开的都是什么文件 procfiles 命令 procfiles <process_pid> —— 命令使用方式 # procfiles 184422 Current rlimit: 2147483647 file descriptors    4: S_IFREG mode:0444 dev:10,5 ino:13407 uid:0 gid:0 rdev:0,0       O_RDONLY size:4811  会显示如上所示的信息,4 是 fd,文件在设备10,5上,文件系统的inode是13407下面我们来查看dev:10,5 对应哪块磁盘 # cd /dev # ls -l

ORACLE_HOME的设置与conn / as sysdba

最近发现了这一挺有意思的内容,以前没遇见过这个问题,或者遇见了,但是没有去思考、解决。 先回忆一下过程: 我是为了配置database vault,所以需要重新配置数据库的dbconsole(之前使用EM管理,但是后来EM服务器没人维护……这是另一个故事了)。 使用emca 配置dbconsole时,会要求输入ORACLE_SID 之类的,按说应该使用OS认证,完成数据库操作后,配置oc4j,一切ok……但是我操作的时候,提示我,不能连接到Oracle Instance,可能是实例未启动或者是ORACLE_HOME环境变量设置不正确——emca非常友好,还特别指出,可能ORACLE_HOME设置为以 / 符号结尾了,这样会导致emca不能连接到实例。 我查看了一下ORACLE_HOME,确实是以 / 符号结尾的(比如/oracle/app/product/11.2/),这时我并没有思考,只是简单想,有没有 / 符号,其实应该没区别的,既然emca认为不要有 / ,那我们就去除 / (如 /oracle/app/product/11.2)。 修改完环境变量后,重新运行emca,错误没有进展…… 这时有点挠头,用sqlplus / as sysdba 登陆数据库实例,检查一下哪有问题,这时候,我们发现 会显示为 connect to idle instance…… 这时我才意识到,启动Oracle Instance时的ORACLE_HOME,跟现在运行sqlplus时的ORACLE_HOME是不一样的,区别是少了一个 / 符号。这种情况下可能就没法连上实例了(这时候通过TNS连接还是可以的)。 总结一下来说,就是ORACLE_HOME设置不能以 / 结尾,否则emca没法设置。 这事有点坑人,如果是生产库,修改ORACLE_HOME,还得重启Instance…… 代价太大了。

RMAN backup copy 在DataGuard中的使用

DataGuard环境中,在Standby端,由于使用OMF的原因,在restore、recover等等操作之后,可能导致数据文件位置与Control File中记录不一致情况:1. 由于使用ASM,以及使用了不同于Primary的db_unique_name,数据文件在不同的DiskGroup位置2. ASM中的OMF文件,可能出现文件名不一致 File Size(MB) Tablespace RB segs Datafile Name ---- -------- ----------------- ------- ------------------------1    0         SYSTEM            ***     +DG1/prod/datafile/system.423.756840583 2    0         UNDOTBS1          ***     +DG1/prod/datafil/undotbs1.258.667475049 3    0         SYSAUX       

对比Kubernetes和OpenShift 2/2

6. A different approach to deployments 像前文Ingress/Router类似,OpenShift选择采用不同的方式管理部署。在Kubernetes中,有Deployment对象(您也可以在OpenShift中使用它们与所有其他Kubernetes对象一起使用)负责以滚动更新方式更新pod,并在控制器内部实现。 OpenShift有一个名为DeploymentConfig的类似对象,不是由控制器实现的,而是由基于专用pod控制整个过程的复杂逻辑实现的。它有一些缺点,但相对Kubernetes Deployment也有一个显著优势 - 你可以使用钩子(Hook)来准备你的环境以进行更新 - 例如通过更改数据库架构。这是一个很难用Deployment实现的功能(不,InitContainers不是一回事,因为它很难与许多运行的实例协调)。但是,在处理多个并发更新时,Kubernetes Deployment更好--DacementConfig根本不支持并发更新,而在Kubernetes中,您可以拥有许多并发更新,并且它将设法正确地扩展它们。 哪一个更好? OpenShift DeploymentConfig有更多选项并支持ImageStream,所以我选择它来替代传统的Kubernetes Deployment。 7. Better management of container images 这是我在Kubernetes中非常想要的,也是我个人最喜欢的OpenShift功能。 用于管理容器镜像的ImageStreams。 你知道在传统容器注册表中更改镜像的标签(Tag)有多“简单”吗? 如果没有skopeo等外部工具,您需要下载整个镜像,在本地更改并将其推回Registry。 通过更改容器标记和更新Deployment对象定义来提升应用程序也不是一种愉快的方法。 这就是我喜欢ImageStreams的原因,以下是主要原因和特点: 使用ImageStream,您可以上传一个容器镜像,然后在OpenShift内部管理它的虚拟标记(tag) - 在一个项目中,您将始终使用devel标记并仅在内部更改对它的引用,在prod上您将使用stable或prod标记并在内部管理它 在OpenShift中,不需要对注册表进行处理操作! 当使用带有DeploymentConfig的ImageStream时,您可以设置一个触发器(触发器/Hook),当新镜像出现或标签更改其引用时自动开始部署操作 - 它非常适合开发环境,其中app会在构建新版本时自行部署(无需任何CICD操作!) 使用触发器,您可以实现更多 - 当基础镜像发布新版本时,使用链式构建来创建我们的应用程序/工具的更新版本  您可以通过将镜像曝光为ImageStream来隐藏镜像本身 - 例如 jenkins指向一个原始的官方镜像,当你想要修改一些东西时,你构建自己的,将它推入你的注册表并仅需要更改ImageStream中的引用,而不是像传统的docker镜像那样部署配置 哪一个更好? OpenShift中的ImageStreams更赞! 8. Integrated CI/CD with Jenkins Red Hat在创建Kubernetes项目之前很久就创建了OpenShift,从一开始,它就是一个PaaS平台。 通过从他们的自定义解决方案(他们使用称为gears而不是容器的东西)切换到Kubernetes,更容易带来更多功能,其中最令人兴奋的是集成Jenkins。 有多种CI / CD软件解决方案,但Jenkins仍然是最大,使用最广泛,通用和成熟的解决方案。 它还经常与Kubernetes集群一起用于构建容器镜像,对它们执行持续集成任务,并将它们作为容器部署在具有Continuous

对比Kubernetes和OpenShift 1/2

10 most important differences between OpenShift and Kubernetes OpenShift经常被其供应商Red Hat称为“企业Kubernetes”。 在本文中,我描述了OpenShift和Kubernetes之间的真正差异。 它经常令人困惑,因为Red Hat倾向于将其描述为PaaS,有时隐藏Kubernetes是OpenShift不可或缺的一部分,OpenShift只是包含更多功能。 让我们深入研究一下这两者之间的真正差异。 1. OpenShift product vs. Kubernetes project Kubernetes是一个开源项目(甚至是一个框架),而OpenShift是一个有很多变种的产品。 有一个OpenShift的开源版本,叫做OKD。 以前它被称为OpenShift Origin,但Red Hat的一些“聪明”人提出了这个新名称,它的意思是“为Red Hat OpenShift提供动力的Kubernetes的原始社区发行版”(?)。 但是让我们先不要纠缠于它的名字,来关注它的含义。以下几点: OpenShift Container Platform是一种可以在您的基础架构上安装的产品,其中包含订阅后附带的付费技术支持 您需要为集群续订OpenShift订阅,并在群集增长时支付更多费用 Kubernetes有很多发行版,但它是一个项目,如果发生了不好的事情,你可以主要依靠社区或外部专家(在某些情况下,他们有时可能比Red Hat支持更好:-)) Kubernetes每年有很多版本(实际上有4个版本),OpenShift也有很多版本,但它落后于Kubernetes发布时间表 - 目前只有一个版本(OpenShift 3.10包括Kubernetes 1.10,而本文撰写本文时的最新版本是1.11) 作为产品,OpenShift订阅包括CloudForms,通过其功能增强它(例如可配置的退款,监控,中央配置等) OKD版本是免费使用的,包括其商业产品的大部分功能,但您不能购买技术支持,也不能使用基于Red Hat的官方容器镜像 因此,如果您需要Kubernetes的支持,一个选项是购买OpenShift的订阅。 如果你对自我支持感觉不错,那么当然还有Kubernetes有很多辅助项目,整个生态系统和梦幻般的社区。 对于犹豫不决的项目,有一个几乎拥有所有OpenShift功能的OKD项目 - 您可以稍后决定迁移到商业产品或坚持使用OKD。所以,从这个角度,哪一个更好?这取决于你是否愿意支付和使用RedHat的技术支持以及产品附带的所有功能(OpenShift)而不是项目(Kubernetes,还有OKD)和自助(没有技术支持)模型。 2. OpenShift limited installation vs. install Kubernetes (almost)

恢复文件夹权限设置

find -depth -printf '%m:%u:%g:%p\0' |awk -v RS='\0' -F: 'BEGIN { print "#!/bin/sh"; print "set -e"; q = "\047";}{ gsub(q, q q "\\" q); f = $0; sub(/^[^:]*:[^:]*:[^:]*:/, "", f); print "chown --", q $2 ":" $3 q, q f q; print "chmod", $1, q f q;}' > restore-permissions.sh

Oracle RAC interconnect Traffic 监控

Oracle在AWR中提供了Estd Interconnect traffic(KB)指标,由于AWR默认只能查看小时级别的数据,做准实时监控需要以更小的时间粒度来计算这个指标。AWR怎么算的看不到,我们可以查看statspack计算这一指标的方法,在sprepins.sql中可以发现Statspack的计算公式: Estd Interconnect traffic = ((Global Cache blocks received + Global Cache blocks served)*db_block_size +(GCS/GES messages received + GCS/GES messages sent)*200)/elapsed time 在Oracle statistics中,Global Cache Blocks received等的名字转换参见如下SQL: SELECTDECODE(name,'gc cr blocks received','global cache blocks received','gc cr blocks served','global cache blocks served','gc current blocks received','global cache blocks received','gc current blocks served','global cache blocks served',name) AS