分类 IT技术 下的文章

Mac下homebrew 更新及重启服务

Brew 是 Mac 下面的包管理工具,通过 Github 托管适合 Mac 的编译配置以及 Patch,可以方便的安装开发工具。
因为个人记忆力不好, 经常忘记命令,所以把常用到的命令记录如下:

 brew doctor                        #自检
 brew update                        #更新brew可安装包,建议每次执行一下
 brew search php55                  #搜索php5.5
 brew tap josegonzalez/php          #安装扩展<gihhub_user/repo>   
 brew tap                           #查看安装的扩展列表
 brew install php55                 #安装php5.5
 brew remove  php55                 #卸载php5.5
 brew upgrade php55                 #升级php5.5
 brew options php55                 #查看php5.5安装选项
 brew info    php55                 #查看php5.5相关信息
 brew home    php55                 #访问php5.5官方网站
 brew services list                 #查看系统通过 brew 安装的服务
 brew services cleanup              #清除已卸载无用的启动配置文件
 brew services restart php55        #重启php-fpm

Hybrid App开发入门(一)

1、什么是Hybrid App?

介绍Hybrid App之前首先需要了解目前主流手机应用程序有哪些?

  • Native App

  • Web App

  • Hybrid App

HyBrid App开发入门

Native App 是一个原生程序,一般运行在机器操作系统上,有很强的交互,一般静态资源都是在本地的。浏览使用方便,体验度高。在实现上要么使用Objecttive-c/swift和cocoaTouch Framework撰写IOS程序,要么选择java+Android Framework撰写android应用程序,具备设备访问能力。

Web App 是生存在浏览器里的应用,所以只能运行在浏览器里,宿主是浏览器,不再是操作系统。资源一般都在网络上。本质上是一个触屏版的网站。不具备设备访问能力。

Hybrid App 是指介于web-app、native-app这两者之间的app,它虽然看上去是一个Native App,但只有一个UI WebView,里面访问的是一个Web App,但是还是运行在机器的操作系统上,交互较弱,资源一般在本地或者网络都可以。具备设备访问能力。

三者优缺点对比

应用类型优点缺点
Native App(1). 打造完美的用户体验 (2). 性能稳定 (3). 操作速度快,上手流畅 (4). 访问本地资源(通讯录,相册) (5). 设计出色的动效,转场 (6). 拥有系统级别的贴心通知或提醒 7.用户留存率高(1). 分发成本高(不同平台有不同的开发语言和界面适配) (2). 维护成本高(例如一款App已更新至V5版本, 但仍有用户在使用V2, V3, V4版本, 需要更多的开发人员维护之前的版本) (3). 更新缓慢,根据不同平台, 提交–审核–上线 等等不同的流程,需要经过的流程较复杂
Web App(1). 开发成本低 (2). 更新快 (3). 更新无需通知用户,不需要手动升级 (4). 能够跨多个平台和终端(1). 临时性的入口 (2). 无法获取系统级别的通知,提醒,动效等 (3). 用户留存率低 (4). 设计受限制诸多 (5). 体验较差
Hybrid App(1). 跨平台,一次开发,所有平台生效 (2). 快速发布,应用内更新不需要提交到AppStore (3). 开发高效成本低,通过HTML+CSS+Javascript开发应用 (4). 丰富的Device API, 通过桥接可以直接调用设备API(1). 图形和动画渲染效果较差,CPU/GPU密集类应用目前看更适合Native (2). 静态资源从服务器端加载导致的UI展示延迟问题

三者属性对比

类型WebHybridNative
开发成本
维护更新简单简单复杂
体验
应用市场认可不认可认可认可
安装不需要需要需要
跨平台
图像渲染HTML,Canvas,CSS混合本地API渲染
原生界面模仿部分原生,部分模仿原生
原生API不可调用可调用可调用
网络要求全部依赖大部分依赖支持离线

2.Hybrid App开发方案

方案一 重混合应用, 在开发原生应用的基础上,嵌入WebView但是整体的架构使用原生应用提供,一般这样的开发由Native开发人员和Web前端开发人员组成。Native开发人员会写好基本的架构以及API让Web开发人员开发界面以及大部分的渲染。保证到交互设计,以及开发都有一个比较折中的效果出来,优化得好也会有很棒的效果。 
Hybrid App技术发展的早期, Web的运行性能成为主要瓶颈!
为解决性能问题Hybrid App走向“ 重混”。

通过多WebView:实现流畅的多页加载和专场动画。

使用Navtive UI 组件:框架、菜单、日期等。

“重混”的优缺点

优点

– 提升了运行性能
– 增强了交互体验

缺点

– Web和Native技术交叉混杂
– 需要同时掌握Web和Native技术, 学习难度增加
– 一个页面有Web组件也有Native组件, 编程调试困难

方案二:轻混合应用, 使用PhoneGap、AppCan之类的中间件,以WebView作为用户界面层,以Javascript作为基本逻辑,以及和中间件通讯,再由中间件访问底层API的方式,进行应用开发。这种架构一般会非常依赖WebView层的性能。
随着时代的发展, 手机硬件、浏览器技术、无线网络技术都得到了大幅的提升,H5已经可以支持复杂应用, 并拥有良好的运行性能。使用轻混方案的App也越来越多。

目前我们要学习的Hybrid App开发就是方案二, 使用H5+Js+Native框架开发当前轻混合应用。

顺变提一下, 2012年8月, 微信公众平台的上线,重新定义了移动应用: 移动应用 = Iphone App + Android App + 微信App

3.Hybrid框架结构

HyBrid App = H5 App + Native框架

  • H5App 用来实现功能逻辑和页面渲染

  • Native框架 提供WebView和设备接口供H5调用

H5 App

简单理解就是以网页技术为主来实现的移动应用。H5 App由网页和外壳两部分组成。 网页主要负责界面的显示和交互; 而外壳会内置一个浏览器来提供网页的运行环境, 并且会通过插件为网页提供扩展的原生调用能力,如下图:
H5架构.png

H5 App简单分为:
  • 多页应用模式MPA( Multi Page Application)

MPA.png

  • 单页应用模式SPA( Single Page Application)

SPA.png

综合上图对比, H5 App页面框架的最佳选择:SPA单页应用模式!!

单页应用的核心问题: 页面隔离! 解决方案如下图所示:

图片1.png
图片2.png

Native框架:

Cordova(PhoneGap)

业界最主流的开源移动跨端框架

HTML + CSS + JS + 原生插件
开放式的原生插件框架
干净的轻混合跨端框架

 
支持公司:
company.png

Hybrid App开发所需技能一览表

  • HTML5

  • CSS3

  • JavaScript

    JavaScript基础:基本语法、面向对象等,能使用JavaScript编写程序。
    Angular : 优秀前端JS框架
    RequireJs : 模块隔离,资源按需加载
    WebPack: 模块加载器兼打包工具
    Avalon: MVVM数据绑定框架(选学)
    Node.js: 服务器端语言, 会这个就前后端统统可以搞定,瞬间成全栈工程师 
Hybrid App开发框架推荐
  • Framework7

  • Ionic


下次分享如何开发一个简单的Hybrid App:

  • Cordova使用

  • 如何使用Cordova插件访问设备接口

  • 如何将H5App打包成App

CentOS6.5安装为PHP安装memcached扩展

PHP环境版本

CentOS6.5的PHP版本为5.6.21通过yum方式安装的, memcache扩展已经通过yum 方式安装好了

首先需要下载并安装libmemcached

因为memcached扩展是基于libevent的事件处理的, 首先需要安装libmemcached
下载地址
解压并安装:

tar zxf libmemcached-1.0.18.tar.gz
cd libmemcached-1.0.18
./configure --prefix=/usr/local/libmemcached --with-memcached//注意:--with-memcached这个选项一定要加上
make
make install

注意:如果需要适用sasl, 也可以在安装libmemcahced前安装cyrus-sasl-devel:

yum install cyrus-sasl-devel

安装memcached扩展

首先下载memcached扩展, 下载地址
解压并安装:

tar zxf memcached-2.2.0.tgz
cd zxf memcached-2.2.0
phpize
./configure --with-php-config=/usr/bin/php-config --disable-memcached-sasl --with-libmemcached-dir=/usr/local/libmemcached
make
make test
make install

注意:如果不使用--disable-memcached-sasl安装过程中会提示

error 'configure: error: no, sasl.h is not available. Run configure with --disable-memcached-sasl to disable this check '

至此php的memcached扩展安装完毕, 重启php-fpm 即可生效。

在CentOS上Let's Encrypt免费SSL证书安装配置Nginx站点

Let’sEncrypt简介

通过提供免费的数字认证,Let’sEncrypt 项目鼓励更多网站采用加密连接。该项目由互联网安全研究集团(ISRG)负责,除 Mozilla 之外,参与 ISRG 这一项目的其他公司还包括思科、Akamai、电子前线基金会和 IdenTrust。该组织还在网站上列出了一些赞助商,包括 Chrome 和 Facebook。自其2012年推出,去年12月份进入公开测试阶段,已经为380万域名提供了免费的安 全防护措施,Let's Encrypt向广大的网站提供免费SSL证书,不管是对于网站站长、互联网用户,还是对整个Web互联网,都是非常有利的,它有利于整个互联网的安全。

HTTPS的必要性

  • HTTPS在客户端和服务器之间传输加密内容,即使被窃听,也极难解密;而HTTP明文传输,攻击者很容易窃听。
  • 防止被劫持,天朝的运营商劫持、挂广告还是比较猖獗的,普及HTTPS非常必要的。

HTTPS不能保证绝对的安全,但能极大地提高攻击/劫持的门槛和代价。

自从DNSpod 可以通过 Lets Encrypt 的验证之后,作者立马也安装上该证书了。
首先说明下安装服务器环境:

  • CentOS 6.7
  • Nginx1.8 + PHP5.6.21 + MySQL5.5.45

安装步骤

1、安装Git、BC、EPEL

yum -y install git bc epel-release

2、下载Let’s Encrypt

git clone https://github.com/letsencrypt/letsencrypt
mv letsencrypt /opt

letsencrypt被安装到/opt/letsencrypt/目录

3、以Diffie-Hellman(迪菲-郝尔曼)生成密钥

openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

4、申请Let’s Encrypt认证,注意修改如下选项

--email 是申请者的使用邮箱地址
-d 是申请的域名
--webroot 是网站根目录

mkdir -p /var/www/www.lezhzihe.net/.well-known/acme-challenge
cd /opt/letsencrypt
./letsencrypt-auto certonly --email lezhizhe_net@163.com -d "www.lezhizhe.net" --webroot -w /var/www/www.lezhizhe.net/ --agree-tos

成功后会产生三个文件,分别是

/etc/ssl/certs/dhparam.pem
/etc/letsencrypt/live/www.lezhizhe.net/fullchain.pem
/etc/letsencrypt/live/www.lezhizhe.net/privkey.pem

5、修改Nginx站点配置

修改站点配置文件如下:

listen 443 ssl;
server_name www.lezhizhe.net;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_certificate /etc/letsencrypt/live/www.lezhizhe.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.lezhizhe.net/privkey.pem;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
  • 修改后检测配置是否正确:
nginx -t
  • 重新加载Nginx配置
nginx -s reload
  • 访问站点检查是否可以正常https方式打开, 如果开启防火墙需要开放443端口!

6、自动更新SSL证书设置

因为Let’s Encrypt的证书有效期是3个月,需要设置定时任务每个月更新一次证书。注意修改该脚本下的邮箱地址、域名he网站根目录。

mkdir -p /etc/letsencrypt/configs
cat >> /etc/letsencrypt/configs/www.lezhizhe.net.conf <<EOF
domains = www.lezhizhe.net
rsa-key-size = 2048
server = https://acme-v01.api.letsencrypt.org/directory
email = lezhizhe_net@163.com
text = True
authenticator = root
webroot-path = /var/www/www.lezhizhe.net/
EOF

自动更新shell脚本如下:
renew-letsencrypt.sh

#!/bin/sh

cd /opt/letsencrypt/
./letsencrypt-auto certonly --config /etc/letsencrypt/configs/www.lezhizhe.net.conf --agree-tos

if [ $? -ne 0 ]
then
ERRORLOG=`tail /var/log/letsencrypt/letsencrypt.log`
echo -e "The Let's Encrypt cert has not been renewed! \n \n" \
$ERRORLOG
else
nginx -s reload
fi

exit 0

修改为可执行权限

chmod +x /root/renew-letsencrypt.sh
crontab -e

@monthly cd /opt/letsencrypt && git pull
@monthly /root/renew-letsencrypt.sh

Redis持久化

概述

Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的。所以,我们需要将内存中的数据持久化!典型的需要持久化数据的场景如下:

  • 将Redis作为数据库使用;
  • 将Redis作为缓存服务器使用,但是缓存miss后会对性能造成很大影响,所有缓存同时失效时会造成服务雪崩,无法响应。

本文介绍Redis所支持的两种数据持久化方式。

Redis数据持久化

Redis支持两种数据持久化方式:RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上,后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用,但是通常会将两者结合使用。

RDB方式

RDB方式的持久化是通过快照的方式完成的。当符合某种规则时,会将内存中的数据全量生成一份副本存储到硬盘上,这个过程称作”快照”,Redis会在以下几种情况下对数据进行快照:

  • 根据配置规则进行自动快照;
  • 用户执行SAVE, BGSAVE命令;
  • 执行FLUSHALL命令;
  • 执行复制(replication)时。
  • 执行快照的场景
根据配置自动快照

Redis允许用户自定义快照条件,当满足条件时自动执行快照,快照规则的配置方式如下:

save 900 1
save 300 10
save 60 10000

每个快照条件独占一行,他们之间是或(||)关系,只要满足任何一个就进行快照。上面配置save后的第一个参数T是时间,单位是秒,第二个参数M是更改的键的个数,含义是:当时间T内被更改的键的个数大于M时,自动进行快照。比如save 900 1的含义是15分钟内(900s)被更改的键的个数大于1时,自动进行快照操作。

执行SAVE或BGSAVE命令

除了让Redis自动进行快照外,当我们需要重启,迁移,备份Redis时,我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作。

  • SAVE命令:当执行SAVE命令时,Redis同步进行快照操作,期间会阻塞所有来自客户端的请求,所以放数据库数据较多时,应该避免使用该命令;
  • BGSAVE命令: 从命令名字就能看出来,这个命令与SAVE命令的区别就在于该命令的快照操作是在后台异步进行的,进行快照操作的同时还能处理来自客户端的请求。执行BGSAVE命令后Redis会马上返回OK表示开始进行快照操作,如果想知道快照操作是否已经完成,可以使用LASTSAVE命令返回最近一次成功执行快照的时间,返回结果是一个Unix时间戳。
执行FLUSHALL命令

当执行FLUSHALL命令时,Redis会清除数据库中的所有数据。需要注意的是:不论清空数据库的过程是否触发 了自动快照的条件,只要自动快照条件不为空,Redis就会执行一次快照操作,当没有定义自动快照条件时,执行FLUSHALL命令不会进行快照操作。

执行复制

当设置了主从模式时,Redis会在复制初始化是进行自动快照。

快照原理

Redis默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中,可以通过配置文件中的dir和dbfilename两个参数分别指定快照文件的存储路径和文件名,例如:

dbfilename dump.rdb
dir /opt/soft/redis-3.0.4/cache

快照执行的过程如下:

  • Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
  • 父进程继续处理来自客户端的请求,子进程开始将内存中的数据写入硬盘中的临时文件;
  • 当子进程写完所有的数据后,用该临时文件替换旧的RDB文件,至此,一次快照操作完成。

需要注意的是:

在执行fork是时候操作系统(类Unix操作系统)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻,父进程和子进程共享同一块内存数据,当父进程需要修改其中的某片数据(如执行写命令)时,操作系统会将该片数据复制一份以保证子进程不受影响,所以RDB文件存储的是执行fork操作那一刻的内存数据。所以RDB方式理论上是会存在丢数据的情况的(fork之后修改的的那些没有写进RDB文件)。

通过上述的介绍可以知道,快照进行时时不会修改RDB文件的,只有完成的时候才会用临时文件替换老的RDB文件,所以就保证任何时候RDB文件的都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据的备份。RDB文件是经过压缩处理的二进制文件,所以占用的空间会小于内存中数据的大小,更有利于传输。

Redis启动时会自动读取RDB快照文件,将数据从硬盘载入到内存,根据数量的不同,这个过程持续的时间也不尽相同,通常来讲,一个记录1000万个字符串类型键,大小为1GB的快照文件载入到内存需要20-30秒的时间。

示例

下面演示RDB方式持久化,首先使用配置有如下快照规则:

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /opt/soft/redis-3.0.4/cache

的配置文件/opt/soft/redis-3.0.4/conf/redis.conf启动Redis服务:

然后通过客户端设置一个键值:

[root@localhost~]$ /opt/soft/redis-3.0.4/src/redis-cli -p 6379
127.0.0.1:6379> set test-rdb HelloWorld
OK
127.0.0.1:6379> get test-rdb
"HelloWorld"
127.0.0.1:6379>

现在强行kill Redis服务:

现在到/opt/soft/redis-3.0.4/cache目录看,目录下出现了Redis的快照文件dump.rdb:

[root@localhost/opt/soft/redis-3.0.4/cache]$ ls
dump.rdb

现在重新启动Redis:

然后再用客户端连接,检查之前设置的key是否还存在:

[qifuguang@Mac~]$ /opt/soft/redis-3.0.4/src/redis-cli -p 6379
127.0.0.1:6379> get test-rdb
"HelloWorld"
127.0.0.1:6379>

可以发现,之前设置的key在Redis重启之后又通过快照文件dump.rdb恢复了。

AOF方式

在使用Redis存储非临时数据时,一般都需要打开AOF持久化来降低进程终止导致的数据丢失,AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这已过程显然会降低Redis的性能,但是大部分情况下这个影响是可以接受的,另外,使用较快的硬盘能提高AOF的性能。

开启AOF

默认情况下,Redis没有开启AOF(append only file)持久化功能,可以通过在配置文件中作如下配置启用:

appendonly yes

开启之后,Redis每执行一条写命令就会将该命令写入硬盘中的AOF文件。AOF文件保存路径和RDB文件路径是一致的,都是通过dir参数配置,默认文件名是:appendonly.aof,可以通过配置appendonlyfilename参数修改,例如:

appendonlyfilename appendonly.aof
AOF持久化的实现

AOF纯文本的形式记录了Redis执行的写命令,例如在开启AOF持久化的情况下执行如下命令:

[root@localhost/opt/soft/redis-3.0.4]$ ./src/redis-cli
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379> set aof1 value1
OK
127.0.0.1:6379> set aof2 value2
OK
127.0.0.1:6379>

然后查看/opt/soft/redis-3.0.4/cache/appendonly.aof文件:

[root@localhost/opt/soft/redis-3.0.4/cache]$ cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
aof1
$6
value1
*3
$3
set
$4
aof2
$6
value2

文件中的内容正是Redis刚才执行的命令的内容,内容的格式就先不展开叙述了。

AOF文件重写

假设Redis执行了如下命令:

[root@localhost/opt/soft/redis-3.0.4]$ ./src/redis-cli
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379> set k v1
OK
127.0.0.1:6379> set k v2
OK
127.0.0.1:6379> set k v3
OK
127.0.0.1:6379>

如果这所有的命令都写到AOF文件的话,将是一个比较蠢行为,因为前面两个命令会被第三个命令覆盖,所以AOF文件完全不需要保存前面两个文件,事实上Redis确实就是这么做的。删除AOF文件中无用的命令的过程成为”AOF重写”,AOF重写可以在配置文件中做相应的配置,当满足配置的条件时,自动进行AOF重写操作。配置如下:

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

第一行的意思是,目前的AOF文件的大小超过上一次重写时的AOF文件的百分之多少时再次进行重写,如果之前没有重写过,则以启动时AOF文件大小为依据。
第二行的意思是,当AOF文件的大小大于64MB时才进行重写,因为如果AOF文件本来就很小时,有几个无效的命令也是无伤大雅的事情。
这两个配置项通常一起使用。

我们还可以手动执行BDREWRITEAOF命令主动让Redis重写AOF文件,执行重写命令之后查看现在的AOF文件:

[root@localhost/opt/soft/redis-3.0.4]$ cat cache/appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$4
aof2
$6
value2
*3
$3
SET
$1
k
$2
v3
*3
$3
SET
$4
aof1
$6
value1

可以看到,文件中并没有再记录set k v1这样的无效命令。

同步硬盘数据

虽然每次执行更改数据库的内容时,AOF都会记录执行的命令,但是由于操作系统本身的硬盘缓存的缘故,AOF文件的内容并没有真正地写入硬盘,在默认情况下,操作系统会每隔30s将硬盘缓存中的数据同步到硬盘,但是为了防止系统异常退出而导致丢数据的情况发生,我们还可以在Redis的配置文件中配置这个同步的频率:

# appendfsync always
appendfsync everysec
# appendfsync no

第一行表示每次AOF写入一个命令都会执行同步操作,这是最安全也是最慢的方式;
第二行表示每秒钟进行一次同步操作,一般来说使用这种方式已经足够;
第三行表示不主动进行同步操作,这是最不安全的方式。

原文链接