Spring的Interceptor(拦截器)与Servlet的Filter有相似之处，都能实现权限检查、日志记录等。不同的是：
| Filter | Interceptor | Summary |
|---|---|---|
| Filter 接口定义在 javax.servlet 包中 | 接口 HandlerInterceptor 定义在org.springframework.web.servlet 包中 | |
| Filter 定义在 web.xml 中 | ||
| Filter在只在 Servlet 前后起作用。Filters 通常将 请求和响应（request/response） 当做黑盒子，Filter 通常不考虑servlet 的实现。 | 拦截器能够深入到方法前后、异常抛出前后等，因此拦截器的使用具有更大的弹性。允许用户介入（hook into）请求的生命周期，在请求过程中获取信息，Interceptor 通常和请求更加耦合。 | 在Spring构架的程序中，要优先使用拦截器。几乎所有 Filter 能够做的事情， interceptor 都能够轻松的实现1 |
| Filter 是 Servlet 规范规定的。 | 而拦截器既可以用于Web程序，也可以用于Application、Swing程序中。 | 使用范围不同 |
| Filter 是在 Servlet 规范中定义的，是 Servlet 容器支持的。 | 而拦截器是在 Spring容器内的，是Spring框架支持的。 | 规范不同 |
| Filter 不能够使用 Spring 容器资源 | 拦截器是一个Spring的组件，归Spring管理，配置在Spring文件中，因此能使用Spring里的任何资源、对象，例如 Service对象、数据源、事务管理等，通过IoC注入到拦截器即可 | Spring 中使用 interceptor 更容易 |
| Filter 是被 Server(like Tomcat) 调用 | Interceptor 是被 Spring 调用 | 因此 Filter 总是优先于 Interceptor 执行 |
interceptor 的执行顺序大致为：
Spring 中主要通过 HandlerInterceptor 接口来实现请求的拦截，实现 HandlerInterceptor 接口需要实现下面三个方法：
统计请求耗时
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.log4j.Logger;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;
public class ExecuteTimeInterceptor extends HandlerInterceptorAdapter{
private static final Logger logger = Logger.getLogger(ExecuteTimeInterceptor.class);
//before the actual handler will be executed
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response, Object handler)
throws Exception {
long startTime = System.currentTimeMillis();
request.setAttribute("startTime", startTime);
return true;
}
//after the handler is executed
public void postHandle(
HttpServletRequest request, HttpServletResponse response,
Object handler, ModelAndView modelAndView)
throws Exception {
long startTime = (Long)request.getAttribute("startTime");
long endTime = System.currentTimeMillis();
long executeTime = endTime - startTime;
//modified the exisitng modelAndView
modelAndView.addObject("executeTime",executeTime);
//log it
if(logger.isDebugEnabled()){
logger.debug("[" + handler + "] executeTime : " + executeTime + "ms");
}
}
}
例子来源 mkyong
使用mvc:interceptors标签来声明需要加入到SpringMVC拦截器链中的拦截器
<mvc:interceptors>
<!-- 使用bean定义一个Interceptor，直接定义在mvc:interceptors根下面的Interceptor将拦截所有的请求 -->
<bean class="com.company.app.web.interceptor.AllInterceptor"/>
<mvc:interceptor>
<mvc:mapping path="/**"/>
<mvc:exclude-mapping path="/parent/**"/>
<bean class="com.company.authorization.interceptor.SecurityInterceptor" />
</mvc:interceptor>
<mvc:interceptor>
<mvc:mapping path="/parent/**"/>
<bean class="com.company.authorization.interceptor.SecuritySystemInterceptor" />
</mvc:interceptor>
</mvc:interceptors>
可以利用mvc:interceptors标签声明一系列的拦截器，然后它们就可以形成一个拦截器链，拦截器的执行顺序是按声明的先后顺序执行的，先声明的拦截器中的preHandle方法会先执行，然而它的postHandle方法和afterCompletion方法却会后执行。
在mvc:interceptors标签下声明interceptor主要有两种方式：
经过上述两步之后，定义的拦截器就会发生作用对特定的请求进行拦截了。
Servlet 的 Filter 接口需要实现如下方法：
void init(FilterConfig paramFilterConfig) – 当容器初始化 Filter 时调用，该方法在 Filter 的生命周期只会被调用一次，一般在该方法中初始化一些资源，FilterConfig 是容器提供给 Filter 的初始化参数，在该方法中可以抛出 ServletException 。init 方法必须执行成功，否则 Filter 可能不起作用，出现以下两种情况时，web 容器中 Filter 可能无效： 1）抛出 ServletException 2）超过 web 容器定义的执行时间。doFilter(ServletRequest paramServletRequest, ServletResponse paramServletResponse, FilterChain paramFilterChain) – Web 容器每一次请求都会调用该方法。该方法将容器的请求和响应作为参数传递进来， FilterChain 用来调用下一个 Filter。void destroy() – 当容器销毁 Filter 实例时调用该方法，可以在方法中销毁资源，该方法在 Filter 的生命周期只会被调用一次。
Request Filters 可以:
Response Filters 可以:
https://stackoverflow.com/a/8006315/1820217 ↩
@Component, @Service, @Controller 和 @Repository 四个注解在 Spring 中等同于在XML中定义 <bean> 标签，他们注解的对象都是 Spring 的 Bean。@Service，@Controller 和 @Repository 本质上就是 @Component。 @Controller，@Service，@Repository 他们在功能上几乎相同，主要的功能是用来给应用分层。
@Controller: 处理对应的请求，对应表现层（控制层），使用 @RequestMapping 注解来定义请求 Path，在该层中做请求分发，转发，调用Service方法等@Service: 所有业务逻辑放在 Service 中，对应业务层，包括数值计算，业务逻辑，在该层中直接调用持久层的方法@Repository: 持久层，访问数据，保存数据，DAO(Data Access Objects)，比如所有数据库相关的操作@Component: 通用的Spring 组件，generic stereotype for any Spring-managed component，当组件不好归类时可以使用该注解在配置文件中定义
<context:component-scan base-package="com.mycompany.mypackage" />
Spring 就会自动扫描package下所有类，将带有@Component、@Repository、@Service、@Controller 标签的类自动注册到Spring容器。 简而言之，注解的方式省去了过去需要在 XML 中定义 <bean class="..."> 的繁重工作。component-scan 包含了annotation-config标签的作用。 @Repository、@Service、@Controller 这三个注解除了作用于不同的软件层面外，其他使用方式和 @Repository 几乎一致。
除了上面的四个注解外，用户同样也可以创建自定义的注解，然后在注解上标注 @Component，那么，该自定义注解便具有了与所 @Component 相同的功能。
当一个 Bean 被自动检测到时，会根据那个扫描器的 BeanNameGenerator 策略生成它的 bean 名称。默认情况下，对于包含 name 属性的 @Component、@Repository、 @Service 和 @Controller，会把 name 取值作为 Bean 的名字。如果这个注解不包含 name 值或是其他被自定义过滤器发现的组件，默认 Bean 名称会是小写开头的非限定类名。如果你不想使用默认 bean 命名策略，可以提供一个自定义的命名策略。首先实现 BeanNameGenerator 接口，确认包含了一个默认的无参数构造方法。然后在配置扫描器时提供一个全限定类名，如下所示：
<beans ...>
<context:component-scan
base-package="a.b" name-generator="a.SimpleNameGenerator"/>
</beans>
与通过 XML 配置的 Spring Bean 一样，通过上述注解标识的 Bean，其默认作用域是”singleton”，为了配合这四个注解，在标注 Bean 的同时能够指定 Bean 的作用域，Spring 2.5 引入了 @Scope 注解。
可以在定义Component 的时候指定 @Scope("prototype”) 来改变。
@Component
@Scope("prototype")
public class UserService {
private int counter;
}
在一些特殊情况下当我们无法使用注解直接使用 Spring Bean 时，比如在 Filter 中，有一些教程提示我们可以直接使用 ApplicationContext.getBean() 来后去 Bean，但这样的方式不优雅 ，我们可以考虑实现 org.springframework.context.ApplicationContextAware 接口，来动态的根据名字来获取 Bean。文档上
Interface to be implemented by any object that wishes to be notified of the ApplicationContext that it runs in. Implementing this interface makes sense for example when an object requires access to a set of collaborating beans. Note that configuration via bean references is preferable to implementing this interface just for bean lookup purposes.
具体实现如下：
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Component;
@Component
public class ContextProvider implements ApplicationContextAware {
private static ApplicationContext CONTEXT;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
CONTEXT = applicationContext;
}
/**
* Get a Spring bean by type.
**/
public static <T> T getBean(Class<T> beanClass) {
return CONTEXT.getBean(beanClass);
}
/**
* Get a Spring bean by name.
**/
public static Object getBean(String beanName) {
return CONTEXT.getBean(beanName);
}
}
上面的类实现，定义了一个简单的 @Component 实现了 ApplicationContextAware 接口，当 Spring Context 被创建时会被通知到。当被通知后 Spring context 会被放到唯一的静态变量 CONTEXT 中，因此静态方法能够通过 getBean 方法找到相应的 Bean 实例。
getBean 的默认名称是类名（头字母小写），如果想简单自定义Bean名字，可以@Service("serviceNewName") 这样来指定。
可以使用以下方式指定初始化方法和销毁方法：
@PostConstruct
public void init() {
}
@PreDestroy
public void destory() {
}
Spring Bean 是受 Spring IoC 容器管理，由容器进行初始化和销毁的（prototype 类型由容器初始化之后便不受容器管理），通常我们不需要关注容器对 Bean 的初始化和销毁操作，由 Spring 经过构造函数或者工厂方法创建的 Bean 就是已经初始化完成并立即可用的。然而在某些情况下，可能需要我们手工做一些额外的初始化或者销毁操作，这通常是针对一些资源的获取和释放操作。
Spring 2.5 在保留以上两种方式的基础上，提供了对 JSR-250 的支持。JSR-250 规范定义了两个用于指定声明周期方法的注解：@PostConstruct 和 @PreDestroy。这两个注解使用非常简单，只需分别将他们标注于初始化之后执行的回调方法或者销毁之前执行的回调方法上。由于使用了注解，因此需要配置相应的 Bean 后处理器，亦即在 XML 中增加如下一行：
比较上述三种指定生命周期回调方法的方式，第一种是不建议使用的，不但其用法不如后两种方式灵活，而且无形中增加了代码与框架的耦合度。后面两种方式开发者可以根据使用习惯选择其中一种，但是最好不要混合使用，以免增加维护的难度。
一般在开发网站时使用 session 或者 cookie 来处理用户登陆等等权限问题，而在移动应用中要验证用户身份采用登录时给用户生成一个 token（令牌）的方式。每次用户发出需要身份认证的请求时，就需要验证一次 token 是否有效，无效的情况包括 token 无法被解析等。在向不可信环境发送数据时，确保数据经过签名，使用只有自己知道的密钥来签名数据，加密后发送，在取回数据时，确保没有人篡改过。
Python 有个 itsdangerous 包含了很多安全校验 token 验证相关的方案。 itsdangerous 就是这样一个签名校验的工具，内部使用 HMAC 和 SHA1 来签名。基于 Django 签名模块，支持 JSON Web 签名 (JWS), 这个库采用 BSD 协议。
发送方和接收方拥有相同的密钥 secret-key ，发送方使用密钥对发送内容进行签名，接收方使用相同的密钥对接收到的内容进行验证，看是否是发送方发送的内容。
>>> from itsdangerous import Signer
>>> s = Signer('secret-key')
>>> s.sign('my string')
'my string.wh6tMHxLgJqB6oY1uT73iMlyrOA'
签名过的字符串使用 . 分割。验证使用 unsign
>>> s.unsign('my string.wh6tMHxLgJqB6oY1uT73iMlyrOA')
签名有一定的时效性，发送方发送时，带上时间信息，接收方判断多长时间内是否失效
>>> from itsdangerous import TimestampSigner
>>> s = TimestampSigner('secret-key')
>>> string = s.sign('foo')
foo.DlGDsw.dpJ37ffyfNAVufH21lH_yoelnKA
>>> s.unsign(string, max_age=5)
如果验证时间不对会抛出异常
>>> from itsdangerous import Serializer
>>> s = Serializer('secret-key')
>>> s.dumps([1, 2, 3, 4])
>>> s.loads('[1, 2, 3, 4].r7R9RhGgDPvvWl3iNzLuIIfELmo')
>>> from itsdangerous import TimedSerializer
>>> s=TimedSerializer('secret-key')
>>> s.dumps([1,2,3,4])
>>> s.loads('[1, 2, 3, 4].DlGEjg.1yG-U7iBk92FBYAZLezoBv2mfJs')
如果加密过的字符串需要在 URL 中传输，可以使用这种方式。常见的就是在邮件验证 token 中。
>>> from itsdangerous import URLSafeSerializer
>>> s = URLSafeSerializer('secret-key')
>>> s.dumps([1, 2, 3, 4])
'WzEsMiwzLDRd.wSPHqC0gR7VUqivlSukJ0IeTDgo'
>>> s.loads('WzEsMiwzLDRd.wSPHqC0gR7VUqivlSukJ0IeTDgo')
[1, 2, 3, 4]
>>> from itsdangerous import JSONWebSignatureSerializer
>>> s = JSONWebSignatureSerializer('secret-key')
>>> s.dumps({'x': 42})
'eyJhbGciOiJIUzI1NiJ9.eyJ4Ijo0Mn0.ZdTn1YyGz9Yx5B5wNpWRL221G1WpVE5fPCPKNuc6UAo'
from itsdangerous import TimedJSONWebSignatureSerializer as Serializer
s = Serializer('secret-key', expires_in=60)
s.dumps({'id': user.id}) # user 为 model 中封装过的对象
在 Flask 中应用
from itsdangerous import TimedJSONWebSignatureSerializer as Serializer
from itsdangerous import SignatureExpired, BadSignature
from config import config
def gen_token(user, expiration=1440*31*60): # 单位为秒，设定 31 天过期
s = Serializer(config.SECRET_KEY, expires_in=expiration)
return s.dumps({'id': user.id}) # user 为 model 中封装过的对象
装饰器
from functools import wraps
def token_required(func):
@wraps(func)
def wrapper(*args, **kwargs):
token = request.form['token']
s = Serializer(config.SECRET_KEY)
try:
data = s.loads(token)
except SignatureExpired:
return jsonify({'status': 'fail', 'data': {'msg': 'expired token'}})
except BadSignature:
return jsonify({'status': 'fail', 'data': {'msg': 'useless token'}})
kwargs['user_id'] = data['id']
return func(*args, **kwargs)
return wrapper
不同的盐值，生成的签名或者序列化的数值不一样，这里的盐 （SALT）不同于加密算法中的盐值，这里的盐值是用来避免彩虹表破解。
哈希（Hash）算法就是单向散列算法，它把某个较大的集合 P 映射到另一个较小的集合 Q 中，假如这个算法叫 H，那么就有 Q = H（P）。对于 P 中任何一个值 p 都有唯一确定的 q 与之对应，但是一个 q 可以对应多个 p。作为一个有用的 Hash 算法，H 还应该满足：H(p) 速度比较快； 给出一个 q，很难算出一个 p 满足 q = H(p)；给出一个 p1，很难算出一个不等于 p1 的 p2 使得 H(p1)=H(p2)。正因为有这样的特性，Hash 算法经常被用来保存密码————这样不会泄露密码明文，又可以校验输入的密码是否正确。常用的 Hash 算法有 MD5、SHA1 等。
破解 Hash 的任务就是，对于给出的一个 q，反算出一个 p 来满足 q = H(p)。通常我们能想到的两种办法，一种就是暴力破解法，把 P 中的每一个 p 都算一下 H(p)，直到结果等于 q；另一种办法是查表法，搞一个很大的数据 库，把每个 p 和对应的 q 都记录下来，按 q 做一下索引，到时候查一下就知道了。这两种办法理论上都是可以的，但是前一种可能需要海量的时间，后一种需要海量 的存储空间，以至于以目前的人类资源无法实现。
JWT 是一次性认证完毕加载信息到 token 里的，token 的信息内含过期信息。过期时间过长则被重放攻击的风险太大，而过期时间太短则请求端体验太差（动不动就要重新登录）
第三方认证协议 Oauth2.0 RFC6749 ，它采取了另一种方法：refresh_token，一个用于更新令牌的令牌。在用户首次认证后，签发两个 token： 一个为 access_token，用于用户后续的各个请求中携带的认证信息；另一个是 refresh_token，为 access_token 过期后，用于申请一个新的 access_token。
由此可以给两类不同 token 设置不同的有效期，例如给 access_token 仅 1 小时的有效时间，而 refresh_token 则可以是一个月。api 的登出通过 access token 的过期来实现（前端则可直接抛弃此 token 实现登出），在 refresh token 的存续期内，访问 api 时可执 refresh token 申请新的 access token（前端可存此 refresh token，access token 过其实进行更新，达到自动延期的效果）。refresh token 不可再延期，过期需重新使用用户名密码登录。
这种方式的理念在于，将证书分为三种级别：
能否使用 == 来针对 enum 来比较？
答案是：YES, 枚举谨慎的实例化管理允许使用 == 来进行比较，JLS 8.9 Enums 中有Java 语言的规范定义：
枚举类型除了定义时的枚举常量外没有其他实例
如果显示的实例化枚举类型，会产生编译时异常。
final clone方法保证了Enum变量不会被 clone， 序列化的机制也保证了重复的实例在反序列化时不会创建额外的枚举变量。通过反射实例化 Enum 类型是被禁止的。所有这四种方式确保了enum类型不存在额外的实例，除了定义时的常量因为每一个枚举常量只有一个实例，因此使用
==来代替equals方法来比较两个枚举是被允许的.
使用 == 来代替 equals 也存在两点需要注意的问题。
== 不会抛出空指针异常
enum Color { BLACK, WHITE };
Color nothing = null;
if (nothing == Color.BLACK); // runs fine
if (nothing.equals(Color.BLACK)); // throws NullPointerException
不过 == 有编译时类型检查，这一点还是很不错的
enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };
if (Color.BLACK.equals(Chiral.LEFT)); // compiles fine
if (Color.BLACK == Chiral.LEFT); // DOESN'T COMPILE!!! Incompatible types!
对于不可变类，并且该类能够有效的控制实例数量， == 就是可用的。
在 Effective Java 一书中指出：
考虑静态工厂方法代替构造器，它使得不可变类可以确保不存在两个相等的实例，即当且仅当 a==b 时才有 a.equals(b) 成立，如果类能够保证这一点，它的客户端可以使用
==来代替 equals 方法，这样可以提升性能，而枚举类型可以保证这一点。
所以在枚举比较中可以使用 ==：
Ubuntu 16.04 LTS 或者 Ubuntu 17.04 下可以通过 PPA 来安装 Cinnamon，感谢维护者
命令如下：
sudo add-apt-repository ppa:embrosyn/cinnamon
sudo apt update && sudo apt install cinnamon
当安装完成之后，Log out 或者 重启，在登录界面选择 Cinnamon 来使用。
我在使用一段时间之后才发现没有安装 Nemo 的插件，以至于右击都没有压缩的选项，通过一下步骤安装 Nemo 以及相关套件。
安装 Nemo
sudo add-apt-repository ppa:noobslab/mint
sudo apt-get update
sudo apt-get install nemo
安装插件
sudo apt-get install nemo-compare nemo-dropbox nemo-fileroller nemo-pastebin nemo-seahorse nemo-share nemo-preview nemo-rabbitvcs
安装完成之后退出 nemo :
nemo -q
然后重启 nemo 即可。
关于 Nemo 更多的使用，可以参考我博客上另外的文章。
之前有写过 Git alias 的文章, 不过过去很多时间，现在对 Git 命令越来越熟悉就希望更快的提高输入效率，也越来越感受到 alias 的重要性，不管是直接在 bash 中的 alias 还是 Git 的 alias。所以准备找一些合适的 alias 添加到自己的 gitconfig 文件中长期使用。
使用命令的方式添加
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
git config --global alias.type 'cat-file -t'
git config --global alias.dump 'cat-file -p'
git status, git add, git commit, git checkout 和 git branch 是最常见的 git 命令，给他们设置 alias 能提高不少效率。使用以上命令添加 alias ，其实作用等同于直接编辑 HOME 目录下的 gitconfig 文件， vim ~/.gitconfig:
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
type = cat-file -t
dump = cat-file -p
如果这样设置之后就可以使用 git co <branch> 来切换分支了。
可以在 ~/.bashrc 或者 ~/.zshrc 中设置 alias g=git 这样就可以使用 g checkout 来代替 git checkout 了。
split 命令可以用来分割文件，支持按文本分割，也支持二进制分割。常见的格式
split [OPTION]... [FILE [PREFIX]]
输出的结果为多个文件 PREFIXaa，PREFIXab … 默认的大小是 1000 行，默认的 PREFIX 是 x。
如果没有 FILE 文件，或者当 FILE 参数是 - 时，会从标准输入读取。
-C 指定分割文件大小：
split -C 10M large_file.mp4 small
将大文件 large_file.mp4 按照 10M 大小进行分割，并指定分割后文件前缀 small，不指定前缀时， 自动对分割文件名命名，一般以 x 开头
-l 选项后接分割行
split -l 1000 large_file.txt small
split -b 100M data.bak smail
cat small* > new_file.txt
# -*- coding: utf-8 -*-
import logging
import sys
# 获取 logger 实例，如果参数为空则返回 root logger
# 最基本的入口，该方法参数可以为空，默认的 logger 名称是 root，如果在同一个程序中一直都使用同名的 logger，其实会拿到同一个实例，使用这个技巧就可以跨模块调用同样的 logger 来记录日志
logger = logging.getLogger("AppName")
# 指定 logger 输出格式
formatter = logging.Formatter('%(asctime)s %(levelname)-8s: %(message)s')
# 文件日志
file_handler = logging.FileHandler("test.log")
file_handler.setFormatter(formatter) # 可以通过 setFormatter 指定输出格式
# 控制台日志
console_handler = logging.StreamHandler(sys.stdout)
console_handler.formatter = formatter # 也可以直接给 formatter 赋值
# 为 logger 添加的日志处理器
logger.addHandler(file_handler)
logger.addHandler(console_handler)
# 指定日志的最低输出级别，默认为 WARN 级别
logger.setLevel(logging.INFO)
# 输出不同级别的 log
logger.debug('this is debug info')
logger.info('this is information')
logger.warn('this is warning message')
logger.error('this is error message')
logger.fatal('this is fatal message, it is same as logger.critical')
logger.critical('this is critical message')
# 2016-10-08 21:59:19,493 INFO : this is information
# 2016-10-08 21:59:19,493 WARNING : this is warning message
# 2016-10-08 21:59:19,493 ERROR : this is error message
# 2016-10-08 21:59:19,493 CRITICAL: this is fatal message, it is same as logger.critical
# 2016-10-08 21:59:19,493 CRITICAL: this is critical message
# 移除一些日志处理器
logger.removeHandler(file_handler)
# 格式化输出
service_name = "Booking"
logger.error('%s service is down!' % service_name) # 使用 python 自带的字符串格式化，不推荐
logger.error('%s service is down!', service_name) # 使用 logger 的格式化，推荐
logger.error('%s service is %s!', service_name, 'down') # 多参数格式化
logger.error('{} service is {}'.format(service_name, 'down')) # 使用 format 函数，推荐
# 2016-10-08 21:59:19,493 ERROR : Booking service is down!
当你使用 logging 模块记录异常信息时，不需要传入该异常对象，只要你直接调用 logger.error() 或者 logger.exception() 就可以将当前异常记录下来。
# 记录异常信息
try:
1 / 0
except:
# 等同于 error 级别，但是会额外记录当前抛出的异常堆栈信息
logger.exception('this is an exception message')
# 2016-10-08 21:59:19,493 ERROR : this is an exception message
# Traceback (most recent call last):
# File "D:/Git/py_labs/demo/use_logging.py", line 45, in <module>
# 1 / 0
# ZeroDivisionError: integer division or modulo by zero
通过日志名称来区分同一程序的不同模块
logger = logging.getLogger("App.UI")
logger = logging.getLogger("App.Service")
fmt 中允许使用的变量可以参考下表
| %(module)s 调用日志输出函数的模块名 |
| %(funcName)s 调用日志输出函数的函数名 |
| %(created)f 当前时间，用 UNIX 标准的表示时间的浮点数表示 |
| %(relativeCreated)d 输出日志信息时的，自 Logger 创建以来的毫秒数 |
最常用的是 StreamHandler 和 FileHandler, Handler 用于向不同的输出端打 log。
logging 的配置大致有下面几种方式。
通过 basicConfig 配置 logger ： https://docs.python.org/2/library/logging.html#logging.basicConfig
可能的原因有很多，但总结下来无非就一个，日志中使用了重复的 handler
切记添加 handler 时不要重复。
If you write something, and you want to share with the world. And let others use through pip install, you can upload your package to pypi.
Put your code in some fold like douban. Write your own setup.py to give basic info about this lib or package. And you can put a README.md file and LICENSE file
douban-dl/
LICENSE.txt
README.md
setup.py
douban/
__init__.py
__main__.py
other_packages.py
setup file often used to describe your project, you can have a template like this:
from setuptools import setup, find_packages
def readme():
with open('README.md') as f:
return f.read()
requirements = [
"bs4",
"requests"
]
setup(
name='douban-dl',
version='0.0.1',
description='',
long_description=readme(),
packages=['douban',],
url="https://github.com/einverne/douban-dl",
author="einverne",
author_email="your@email.com",
entry_points={
'console_scripts': [
'douban-dl = douban.__main__:main',
]},
keywords="douban downloader",
packages=find_packages(exclude=["tests"]),
license='MIT',
install_requires=requirements,
)
Register your own account at https://pypi.python.org/pypi. And create following file under ~/.pypirc.
[distutils]
index-servers =
pypi
testpypi
[pypi]
username: einverne
password: password
[testpypi]
repository: https://test.pypi.org/legacy
username: einverne
password: password
Use following command to create a compressed archive file which is under dist sub-directory. This file will wrap-up all project’s source code.
python setup.py sdist
And upload
python setup.py sdist [bdist_wininst] upload
this command upload archive file to pypi. bdist_wininst option alse create windows distribution.
All above had beed tested by myself -> https://pypi.python.org/pypi/douban-dl
这篇文章主要介绍 Redis 的持久化机制，主从复制等等
通常情况下 Redis 会将数据存储于内存中，但 Redis 也支持持久化。Redis 支持两种持久化方式，RDB 方式 和 AOF 方式。RDB 通过快照方式，将内存数据写入磁盘。而 AOF 方式则是类似 MySQL 日志方式，记录每次更新的日志。前者性能高，但是可能引起一定的数据丢失，后者相反。
RDB 通过快照 snapshotting 完成，也是 Redis 默认的持久化方式，当符合一定条件时 Redis 会自动将内存中的所有数据以快照方式保存一份副本到硬盘上 (dump.rdb)，这个过程称为”快照”。
Redis 根据以下情况执行快照：
save 900 1 表示在 15min(900s) 时间内，有一个或者一个以上键被更改则进行快照。save 300 10 表示 300 秒内超过 10 个 key 被修改，则发起快照SAVE 命令时， Redis 同步地进行快照操作，会阻塞所有来自客户端的请求。尽量避免在生产环境使用这一命令。
BGSAVE 命令，后台异步进行快照。查看快照是否成功，通过 LASTSAVE 命令获取最近一次成功执行快照时间，返回结果 Unix 时间戳。
FLUSHALL ，Redis 清除数据库所有数据。只要定义了自动快照条件，则会进行快照。如果没有定义自动快照，则不会进行快照。
复制操作时，即使没有定义自动快照条件，也会生成 RDB 快照
Redis 默认将快照文件存储在工作目录中 dump.rdb 文件中，可以通过配置 dir 和 dbfilename 两个参数分别来指定快照文件的存储路径和文件名。
快照的保存过程：
需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘 io 操作，可能会严重影响性能。
快照的方式是一定间隔备份一次，它的缺点就是如果 Redis 意外挂掉的话，就会丢失最后一次快照之后的所有修改。如果应用要求不能丢失任何修改可以采用 AOF 持久化方式。
AOF 将 Redis 执行的每一条写命令追加到硬盘文件中（默认为 appendonly.aof)。默认没有开启 AOF (append only file) ，可以通过 appendonly 参数启用：
appendonly yes
AOF 文件保存位置和 RDB 文件位置相同，通过 dir 参数设置，默认为 appendonly.aof ，通过 appendfilename 参数修改：
appendfilename appendonly.aof
Redis 在重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库。
操作系统会在内核中缓存写命令的修改，因此不是立即存盘，所以也可能会导致部分数据丢失。通过 fsync 函数强制系统写入磁盘的时机， 有三种方式如下（默认是：每秒 fsync 一次）:
appendonly yes # 启用 aof 持久化方式
# appendfsync always # 收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec # 每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
# appendfsync no # 完全依赖 os, 性能最好，持久化没保证
AOF 方式的缺点：
bgrewriteaof 命令。 收到此命令 Redis 将使用与快照类似的方式将内存中的数据以命令方式保存到临时文件中，最后替换原来的文件结构上，容易发生单点故障，分配不同服务器
容量上，内存容易成为存储瓶颈，需要对数据进行分片
集群的特点在于拥有和单机实例同样的性能，同时在网络分区后能够提供一定的可访问性以及对主数据库故障恢复的支持。
复制多副本部署不同服务器，防止一台故障丢失数据。通过主从复制可以允许多个 slave server 拥有和 master server 相同的数据库副本。
主从复制特点：
从数据库配置中：
slaveof 主数据库地址 主数据库端口
当配置好 slave 后，slave 与 master 建立连接，然后发送 sync 命令。无论是第一次连接还是重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，同时 master 主进程会开始收集新的写命令并缓存。后台进程完成写文件后，master 发送文件给 slave, slave 将文件保存到硬盘上，再加载到内存中，接着 master 就会把缓存的命令转发给 slave, 后续 master 将收到的写命令发送给 slave。如果 master 同时收到多个 slave 发来的同步连接命令，master 只会启动一个进程来写数据库镜像，然后发送给所有的 slave。
使用 info 命令来判断当前 redis 是主库还是从库， role 字段，还可以利用 master_link_status 来查看主从是否异步，up 为正常，down 为同步异步。
监控 Redis 运行状况。
Redis 不同命令拥有不同的属性，是否只读命令，是否是管理员命令，一个命令可以拥有多个属性。
REDIS_CMD_WRITE 属性，会修改 Redis 数据库数据REDIS_CMD_DENYOOM 属性，可能增加 Redis 占用的存储空间，显然拥有该属性的命令都拥有 REDIS_CMD_WRITE 属性。REDIS_CMD_NOSCRIPT 属性，无法在 Redis 脚本中执行REDIS_CMD_RANDOM 脚本执行了该属性命令之后，不能执行拥有 REDIS_CMD_WRITE 属性命令REDIS_CMD_SORT_FOR_SCRIPT 产生随机结果REDIS_CMD_LOADING 当 Redis 启动时，只会执行拥有该属性的命令Redis 由单线程处理所有 client 请求，在接收到 client 发送的命令后会立即处理并返回结果，但是当 client 发出 multi 命令后，这个连接会进入事务上下文，连接后续命令并不会立即执行，而是先放到队列中，当收到 exec 命令后，redis 顺序执行队列中所有命令，并将结果一起返回。
get keydemo
multi
set keydemo 10
set keydemo 20
exec
get keydemo
在 multi 开始之后可以使用 discard 来取消事务。
乐观锁，指的是每次拿数据时认为别人不会修改，不上锁，而在提交更新市判断期间是否有别人更新该数据。
乐观锁使用数据库版本记录实现，需要满足提交版本必须大于当前记录版本才能执行更新的乐观锁策略。
Redis 从 2.1 版本开始支持乐观锁，可以使用 watch 显式对 key 加锁。watch 命令会监视给定的 key，在 exec 结束时如果监视 key 从调用 watch 后发生过变化，则事务会失败。
phpRedisAdmin 是一个 PHP 实现的 Redis 管理 Web 界面。地址：https://github.com/erikdubbelboer/phpRedisAdmin