分类 默认分类 下的文章

Message - RabbitMQ

  • 为什么要有消息系统
    消息系统主要用来处理比较耗时的任务, 如一个 http 请求进来之后,可能需要比较长的处理时间, 可以把这个请求封装为一个 message task, 发到消息系统, 等待后端系统处理, 同时返回 http response 郑州处理中.
  • RabbitMQ 的核心概念
    生产者(producer) -> Exchange -> Queue -> Consumer
  • RabbitMQ 如何保证消息不丢失
    当 Producer 发出之后, 它可以通过 Publisher Confirm 来确认一定发出去了;
    Consumer 有可能没处理完就 crash 了, 不过 queue 可以通过 consumer 的 Ack 来确认消息发到 consumer, 被处理, 并且处理完成;
    RabbitMQ 可以持久化(存入硬盘) Queue & Message 来保证消息不丢失;
  • RabbitMQ 的 exchange type
    direct, topic, headers and fanout
  • RabbitMQ server 端的工具命令是: rabbitmqctl
  • Exchange 和 queue 通过 binding 来确认关系: channel.queueBind("queueName", "exchangeName", "");
  • Producer 发送消息到 Exchange, 并带着 routeKey, Exchange 有 exchange type, queue 和 exchange binding, binding 时候可以设置 routeKey, consumer 通过 queue 接受消息.
  • 一般的队列和发布订阅是通过 exchange 的 exchange type 来实现的. 配合 topic 的 routeKey * and # 两个特殊字符

webp 图片格式

webp 读作[weppy], 是 google 于2010年推出的一种有损压缩格式, 比 png 和 jpeg 大幅减少文件大小, 但是转换过程需要更长时间.
现在只有 chrome 和 opera 浏览器支持这种文件格式, 并且保存到 windows, mac, linux 现在都无法打开, 编辑.

facebook 在2013年开始在网站上使用这种格式, 国内的淘宝上面也在使用这种格式. 这种格式会使客户端和服务器端大大减少网络流量, 因为网站的图片占据了网站的大部分流量.

查看浏览器的支持情况, 查看这里: http://caniuse.com/webp
官方: https://developers.google.com/speed/webp/?csw=1

参考: http://en.wikipedia.org/wiki/WebP

Mac 下的 java 安装路径

Mac 上的 Java 安装过好多次 JDK 1.7 但是等到真正在 eclipse 里面切换系统 library 的时候, 却找不到它了, 只在下面的路径看到系统默认的 JDK 1.6

/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/

在 stackoverflow 上查到如下命令:

/usr/libexec/java_home -v 1.7

发现原来另外安装的 JDK 1.7 在下面这个位置:

superman:~ root$ /usr/libexec/java_home -v 1.7
/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home

参考: Where is Java 7 Installed on Mac OS X?

用户注册, 登录, 密码的存储

以下的思路中有的是说的注册过程, 有的是登录的过程, 大概类似, 注册存储到 DB, 验证只是对比结果.
对于单向加密算法, 用的比较多的是 md5 或者 SHA1, 这里以 md5 为例.

最简单, 最原始:
客户端 密码: 123456 -------------> 服务器端 存储到数据库 123456

服务器端加密存储
客户端 密码: 123456 -------------> 服务器端 加密后存储到数据库 md5(123456)

客户端加密 再传输
客户端 先加密: md5(123456) -------------> 服务器端 直接存储到数据库 md5(123456)

加盐 加密 再传输
客户端 获得 salt <-----------------------服务器端 给 salt
客户端 先加盐, 再加密: md5(123456 + salt) -------------> 服务器端 直接存储到数据库 md5(123456 + salt)

加盐 加密 再 https 传输 (安全通道)
客户端 <----------- 建立 ssl 安全通道 ---------------> 服务器端
客户端 获得 salt <-----------https---------服务器端 给 salt
客户端 先加盐, 再加密: md5(123456 + slat) -----https-----> 服务器端 直接存储到数据库 md5(123456 + salt)

加盐 加密 再 https 传输 (安全通道) 一用户一盐
客户端 <----------- 建立 ssl 安全通道 ---------------> 服务器端
客户端 获得本用户的 salt <---------https-------服务器端 从盐表获取当前用户的salt (盐表单独 server, 单独数据, 单独表)
客户端 先加盐, 再加密: md5(123456 + slat) ----https-------> 服务器端 直接存储到数据库 md5(123456 + salt)

加盐 加密 再 https 传输 (安全通道) 一用户一盐 双因子认证
客户端 <----------- 建立 ssl 安全通道 ---------------> 服务器端
客户端 获得本用户的 salt <---------https-------服务器端 从盐表获取当前用户的salt (盐表单独 server, 单独数据, 单独表)
客户端 获得第二个因子, 如 短信验证码, hard token, soft token, 邮箱获取验证码 <==另外方式===> 服务器端
客户端 先加盐, 再加密: md5(123456 + slat) 第二个因子 ----https-------> 服务器端 双因子 认证 加密后密码 + 第二因子