spring整体架构说明

• spring framework
• spring session
• spring security
• spring data
• spring integration
• spring boot

hexo

npm install hexo -g #安装  
npm update hexo -g #升级  
hexo init #初始化

简写

hexo n "我的博客" == hexo new "我的博客" #新建文章
hexo p == hexo publish
hexo g == hexo generate#生成
hexo s == hexo server #启动服务预览
hexo d == hexo deploy#部署

服务器

hexo server #Hexo 会监视文件变动并自动更新，您无须重启服务器。
hexo server -s #静态模式
hexo server -p 5000 #更改端口
hexo server -i 192.168.1.1 #自定义 IP

hexo clean #清除缓存 网页正常情况下可以忽略此条命令
hexo g #生成静态网页
hexo d #开始部署

监视文件变动

hexo generate #使用 Hexo 生成静态文件快速而且简单
hexo generate --watch #监视文件变动

完成后部署

两个命令的作用是相同的

hexo generate --deploy
hexo deploy --generate

hexo deploy -g
hexo server -g

草稿

hexo publish [layout] <title>

模版

hexo new "postName" #新建文章
hexo new page "pageName" #新建页面
hexo generate #生成静态页面至public目录
hexo server #开启预览访问端口（默认端口4000，'ctrl + c'关闭server）
hexo deploy #将.deploy目录部署到GitHub

hexo new [layout] <title>
hexo new photo "My Gallery"
hexo new "Hello World" --lang tw

title: 使用Hexo搭建个人博客
layout: post
date: 2014-03-03 19:07:43
comments: true
categories: Blog
tags: [Hexo]
keywords: Hexo, Blog
description: 生命在于折腾，又把博客折腾到Hexo了。给Hexo点赞。

模版（Scaffold）

hexo new photo "My Gallery"

设置文章摘要

以上是文章摘要 <!--more--> 以下是余下全文 

写作

hexo new page <title>
hexo new post <title>

推送到服务器上

hexo n #写文章
hexo g #生成
hexo d #部署 #可与hexo g合并为 hexo d -g

##报错

1.找不到git部署

ERROR Deployer not found: git

###解决方法

npm install hexo-deployer-git --save

3.部署类型设置git

hexo 3.0 部署类型不再是github，_config.yml 中修改

# Deployment
## Docs: http://hexo.io/docs/deployment.html
deploy:
  type: git
  repository: git@***.github.com:***/***.github.io.git
  branch: master

binlog 基本认识

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景: 
其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。 
其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。 

一、开启binlog日志：

vi编辑打开mysql配置文件
    # vi /usr/local/mysql/etc/my.cnf
    在[mysqld] 区块
    设置/添加 log-bin=mysql-bin  确认是打开状态(值 mysql-bin 是日志的基本名或前缀名)；

    重启mysqld服务使配置生效
    # pkill mysqld
    # /usr/local/mysql/bin/mysqld_safe --user=mysql &

二、也可登录mysql服务器，通过mysql的变量配置表，查看二进制日志是否已开启 单词：variable[ˈvɛriəbəl] 变量

登录服务器
    # /usr/local/mysql/bin/mysql -uroot -p123456

    mysql> show variables like 'log_%'; 
    +----------------------------------------+---------------------------------------+
    | Variable_name                          | Value                                 |
    +----------------------------------------+---------------------------------------+
    | log_bin                                | ON                                    | ------> ON表示已经开启binlog日志
    | log_bin_basename                       | /usr/local/mysql/data/mysql-bin       |
    | log_bin_index                          | /usr/local/mysql/data/mysql-bin.index |
    | log_bin_trust_function_creators        | OFF                                   |
    | log_bin_use_v1_row_events              | OFF                                   |
    | log_error                              | /usr/local/mysql/data/martin.err      |
    | log_output                             | FILE                                  |
    | log_queries_not_using_indexes          | OFF                                   |
    | log_slave_updates                      | OFF                                   |
    | log_slow_admin_statements              | OFF                                   |
    | log_slow_slave_statements              | OFF                                   |
    | log_throttle_queries_not_using_indexes | 0                                     |
    | log_warnings                           | 1                                     |
    +----------------------------------------+---------------------------------------+

三、常用binlog日志操作命令

1.查看所有binlog日志列表

  mysql> show master logs;

2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

  mysql> show master status;

3.刷新log日志，自此刻开始产生一个新编号的binlog日志文件

  mysql> flush logs;
  注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；

4.重置(清空)所有binlog日志

  mysql> reset master;

四、查看某个binlog日志内容，常用有两种方式：

1.使用mysqlbinlog自带查看命令法：

      注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看
          binlog日志与数据库文件在同目录中(我的环境配置安装是选择在/usr/local/mysql/data中)
      在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “--no-defaults”选项
    
      # /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000013
        下面截取一个片段分析：(得知可以用–base64-output=DECODE-ROWS -v查看出来sql语句)

         ...............................................................................
         # at 552
         #131128 17:50:46 server id 1  end_log_pos 665   Query   thread_id=11    exec_time=0     error_code=0 ---->执行时间:17:50:46；pos点:665
         SET TIMESTAMP=1385632246/*!*/;
         update zyyshop.stu set name='李四' where id=4              ---->执行的SQL
         /*!*/;
         # at 665
         #131128 17:50:46 server id 1  end_log_pos 692   Xid = 1454 ---->执行时间:17:50:46；pos点:692 
         ...............................................................................

         注: server id 1     数据库主机的服务号；
             end_log_pos 665 pos点
             thread_id=11    线程号

2.上面这种办法读取出binlog日志的全文内容较多，不容易分辨查看pos点信息，这里介绍一种更为方便的查询命令：

      mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

             选项解析：
               IN 'log_name'   指定要查询的binlog文件名(不指定就是第一个binlog文件)
               FROM pos        指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
               LIMIT [offset,] 偏移量(不指定就是0)
               row_count       查询总条数(不指定就是所有行)

             截取部分查询结果：
             *************************** 20. row ***************************
                Log_name: mysql-bin.000021  ----------------------------------------------> 查询的binlog日志文件名
                     Pos: 11197 ----------------------------------------------------------> pos起始点:
              Event_type: Query ----------------------------------------------------------> 事件类型：Query
               Server_id: 1 --------------------------------------------------------------> 标识是由哪台服务器执行的
             End_log_pos: 11308 ----------------------------------------------------------> pos结束点:11308(即：下行的pos起始点)
                    Info: use `zyyshop`; INSERT INTO `team2` VALUES (0,345,'asdf8er5') ---> 执行的sql语句
             *************************** 21. row ***************************
                Log_name: mysql-bin.000021
                     Pos: 11308 ----------------------------------------------------------> pos起始点:11308(即：上行的pos结束点)
              Event_type: Query
               Server_id: 1
             End_log_pos: 11417
                    Info: use `zyyshop`; /*!40000 ALTER TABLE `team2` ENABLE KEYS */
             *************************** 22. row ***************************
                Log_name: mysql-bin.000021
                     Pos: 11417
              Event_type: Query
               Server_id: 1
             End_log_pos: 11510
                    Info: use `zyyshop`; DROP TABLE IF EXISTS `type`

      这条语句可以将指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数；

A.查询第一个(最早)的binlog日志：

    mysql> show binlog events\G; 

B.指定查询 mysql-bin.000021 这个文件：

    mysql> show binlog events in 'mysql-bin.000021'\G;

C.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起：

    mysql> show binlog events in 'mysql-bin.000021' from 8224\G;

D.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条

    mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10\G;

E.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条

    mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G;

五、恢复binlog日志实验(zyyshop是数据库)

1.假设现在是凌晨4:00，我的计划任务开始执行一次完整的数据库备份：

      将zyyshop数据库备份到 /root/BAK.zyyshop.sql 文件中：
      # /usr/local/mysql/bin/mysqldump -uroot -p123456 -lF --log-error=/root/myDump.err -B zyyshop > /root/BAK.zyyshop.sql
        ......

        大约过了若干分钟，备份完成了，我不用担心数据丢失了，因为我有备份了，嘎嘎~~~

      由于我使用了-F选项，当备份工作刚开始时系统会刷新log日志，产生新的binlog日志来记录备份之后的数据库“增删改”操作，查看一下：
      mysql> show master status;
      +------------------+----------+--------------+------------------+
      | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
      +------------------+----------+--------------+------------------+
      | mysql-bin.000023 |      120 |              |                  |
      +------------------+----------+--------------+------------------+
      也就是说， mysql-bin.000023 是用来记录4:00之后对数据库的所有“增删改”操作。

2.早9:00上班了，业务的需求会对数据库进行各种“增删改”操作~~~~~~~

      @ 比如：创建一个学生表并插入、修改了数据等等：
        CREATE TABLE IF NOT EXISTS `tt` (
          `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
          `name` varchar(16) NOT NULL,
          `sex` enum('m','w') NOT NULL DEFAULT 'm',
          `age` tinyint(3) unsigned NOT NULL,
          `classid` char(6) DEFAULT NULL,
          PRIMARY KEY (`id`)
         ) ENGINE=InnoDB DEFAULT CHARSET=utf8;


      导入实验数据
      mysql> insert into zyyshop.tt(`name`,`sex`,`age`,`classid`) values('yiyi','w',20,'cls1'),('xiaoer','m',22,'cls3'),('zhangsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6');


      查看数据
      mysql> select * from zyyshop.tt;
      +----+----------+-----+-----+---------+
      | id | name     | sex | age | classid |
      +----+----------+-----+-----+---------+
      |  1 | yiyi     | w   |  20 | cls1    |
      |  2 | xiaoer   | m   |  22 | cls3    |
      |  3 | zhangsan | w   |  21 | cls5    |
      |  4 | lisi     | m   |  20 | cls4    |
      |  5 | wangwu   | w   |  26 | cls6    |
      +----+----------+-----+-----+---------+


      中午时分又执行了修改数据操作
      mysql> update zyyshop.tt set name='李四' where id=4;
      mysql> update zyyshop.tt set name='小二' where id=2;

      修改后的结果：
      mysql> select * from zyyshop.tt;
      +----+----------+-----+-----+---------+
      | id | name     | sex | age | classid |
      +----+----------+-----+-----+---------+
      |  1 | yiyi     | w   |  20 | cls1    |
      |  2 | 小二     | m   |  22 | cls3    |
      |  3 | zhangsan | w   |  21 | cls5    |
      |  4 | 李四     | m   |  20 | cls4    |
      |  5 | wangwu   | w   |  26 | cls6    |
      +----+----------+-----+-----+---------+


      假设此时是下午18:00，莫名地执行了一条悲催的SQL语句，整个数据库都没了：
      mysql> drop database zyyshop;

3.此刻杯具了，别慌！先仔细查看最后一个binlog日志，并记录下关键的pos点，到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步)；

      备份一下最后一个binlog日志文件：
      # ll /usr/local/mysql/data | grep mysql-bin
      # cp -v /usr/local/mysql/data/mysql-bin.000023 /root/

      此时执行一次刷新日志索引操作，重新开始新的binlog日志记录文件，理论说 mysql-bin.000023 这个文件不会再有后续写入了(便于我们分析原因及查找pos点)，以后所有数据库操作都会写入到下一个日志文件；
      mysql> flush logs;
      mysql> show master status;

4.读取binlog日志，分析问题

      方式一：使用mysqlbinlog读取binlog日志：
        # /usr/local/mysql/bin/mysqlbinlog  /usr/local/mysql/data/mysql-bin.000023

      方式二：登录服务器，并查看(推荐)：
        mysql> show binlog events in 'mysql-bin.000023';
        
        以下为末尾片段：
        +------------------+------+------------+-----------+-------------+------------------------------------------------------------+
        | Log_name         | Pos  | Event_type | Server_id | End_log_pos | Info                                                       |
        +------------------+------+------------+-----------+-------------+------------------------------------------------------------+
        | mysql-bin.000023 |  922 | Xid        |         1 |         953 | COMMIT /* xid=3820 */                                      |
        | mysql-bin.000023 |  953 | Query      |         1 |        1038 | BEGIN                                                      |
        | mysql-bin.000023 | 1038 | Query      |         1 |        1164 | use `zyyshop`; update zyyshop.tt set name='李四' where id=4|
        | mysql-bin.000023 | 1164 | Xid        |         1 |        1195 | COMMIT /* xid=3822 */                                      |
        | mysql-bin.000023 | 1195 | Query      |         1 |        1280 | BEGIN                                                      |
        | mysql-bin.000023 | 1280 | Query      |         1 |        1406 | use `zyyshop`; update zyyshop.tt set name='小二' where id=2|
        | mysql-bin.000023 | 1406 | Xid        |         1 |        1437 | COMMIT /* xid=3823 */                                      |
        | mysql-bin.000023 | 1437 | Query      |         1 |        1538 | drop database zyyshop                                      |
        +------------------+------+------------+-----------+-------------+------------------------------------------------------------+

        通过分析，造成数据库破坏的pos点区间是介于 1437--1538 之间，只要恢复到1437前就可。

5.现在把凌晨备份的数据恢复：

      # /usr/local/mysql/bin/mysql -uroot -p123456 -v < /root/BAK.zyyshop.sql;

      注: 至此截至当日凌晨(4:00)前的备份数据都恢复了。
          但今天一整天(4:00--18:00)的数据肿么办呢？就得从前文提到的 mysql-bin.000023 新日志做文章了......

6.从binlog日志恢复数据

      恢复语法格式：
      # mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

        常用选项：
          --start-position=953                   起始pos点
          --stop-position=1437                   结束pos点
          --start-datetime="2013-11-29 13:18:54" 起始时间点
          --stop-datetime="2013-11-29 13:21:53"  结束时间点
          --database=zyyshop                     指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志)
            
        不常用选项：    
          -u --user=name              Connect to the remote server as username.连接到远程主机的用户名
          -p --password[=name]        Password to connect to remote server.连接到远程主机的密码
          -h --host=name              Get the binlog from server.从远程主机上获取binlog日志
          --read-from-remote-server   Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志

小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径；

A.完全恢复(本例不靠谱，因为最后那条 drop database zyyshop 也在日志里，必须想办法把这条破坏语句排除掉，做部分恢复)

    # /usr/local/mysql/bin/mysqlbinlog  /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop 

B.指定pos结束点恢复(部分恢复)：

    @ --stop-position=953 pos结束点
    注：此pos结束点介于“导入实验数据”与更新“name='李四'”之间，这样可以恢复到更改“name='李四'”之前的“导入测试数据”
    # /usr/local/mysql/bin/mysqlbinlog --stop-position=953 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop
  
    在另一终端登录查看结果(成功恢复了)：
    mysql> select * from zyyshop.tt;
    +----+----------+-----+-----+---------+
    | id | name     | sex | age | classid |
    +----+----------+-----+-----+---------+
    |  1 | yiyi     | w   |  20 | cls1    |
    |  2 | xiaoer   | m   |  22 | cls3    |
    |  3 | zhangsan | w   |  21 | cls5    |
    |  4 | lisi     | m   |  20 | cls4    |
    |  5 | wangwu   | w   |  26 | cls6    |
    +----+----------+-----+-----+---------+

C.指定pso点区间恢复(部分恢复)：

    更新 name='李四' 这条数据，日志区间是Pos[1038] --> End_log_pos[1164]，按事务区间是：Pos[953] --> End_log_pos[1195]；

    更新 name='小二' 这条数据，日志区间是Pos[1280] --> End_log_pos[1406]，按事务区间是：Pos[1195] --> End_log_pos[1437]；

    c1.单独恢复 name='李四' 这步操作，可这样：
       # /usr/local/mysql/bin/mysqlbinlog --start-position=1038 --stop-position=1164 --database=zyyshop  /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

       也可以按事务区间单独恢复，如下：
       # /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1195 --database=zyyshop  /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop


    c2.单独恢复 name='小二' 这步操作，可这样：
       # /usr/local/mysql/bin/mysqlbinlog --start-position=1280 --stop-position=1406 --database=zyyshop  /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

       也可以按事务区间单独恢复，如下：
       # /usr/local/mysql/bin/mysqlbinlog --start-position=1195 --stop-position=1437 --database=zyyshop  /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop


    c3.将 name='李四'、name='小二' 多步操作一起恢复，需要按事务区间，可这样：
       # /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1437 --database=zyyshop  /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

D.在另一终端登录查看目前结果(两名称也恢复了)：

    mysql> select * from zyyshop.tt;
    +----+----------+-----+-----+---------+
    | id | name     | sex | age | classid |
    +----+----------+-----+-----+---------+
    |  1 | yiyi     | w   |  20 | cls1    |
    |  2 | 小二     | m   |  22 | cls3    |
    |  3 | zhangsan | w   |  21 | cls5    |
    |  4 | 李四     | m   |  20 | cls4    |
    |  5 | wangwu   | w   |  26 | cls6    |
    +----+----------+-----+-----+---------+

E.也可指定时间区间恢复(部分恢复)：除了用pos点的办法进行恢复，也可以通过指定时间区间进行恢复，按时间恢复需要用mysqlbinlog命令读取binlog日志内容，找时间节点。

    比如，我把刚恢复的tt表删除掉，再用时间区间点恢复
    mysql> drop table tt;

    @ --start-datetime="2013-11-29 13:18:54"  起始时间点
    @ --stop-datetime="2013-11-29 13:21:53"   结束时间点

    # /usr/local/mysql/bin/mysqlbinlog --start-datetime="2013-11-29 13:18:54" --stop-datetime="2013-11-29 13:21:53" --database=zyyshop /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

  总结：所谓恢复，就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。

引言

数据源的分类，大体可以分为三类：结构化数据，半结构化数据，非结构化数据

首先，我们面临的数据源多而杂，有来自公司自有平台的数据，来自第三方现有的数据，来自通过爬取获取的数据。

自有平台数据的采集

自有平台的数据包括：自有系统中的数据和各个部门手动整理的历史数据
（1）自有系统的数据，存放在oracle数据库中，而我们抽取的数据统一放在一个数据平台，数据平台采用的数据库为mongodb。所以自有系统的数据采集，关键是如何从oracle到mongodb中。

如果采集的数据对实时性要求比较高，那么采用ogg实时迁移方案。

oracle to oracle迁移方案
oracle to mongodb迁移方案

如果采集数据对实时性要求不高，那么采用定时的迁移方案：使用etl工具进行数据迁移（spoon）

（2）自有数据，还有一部分是以csv或txt的形式存在

如果对实时性要求比较高：使用flume对日志进行收集，然后存放的mongodb中

如果对实时性要求不高：使用mongodbimport工具导入mongodb即可

第三方现有数据的采集半结构化数据

仅有自有的数据是不足以支撑业务需求的分析，所以收集第三方数据是必须的，第三方的数据来源就多种多样了，大体可以二类：来自数据库中的半结构化数据，来自文件的半结构化数据

如果数据来自关系型数据库mysql或oracle，并且提供的是dmp文件，那么就需要将获取的数据存入到mongodb。这里提供两种思路：

（1）先将数据存入oracle或mysql，然后使用上述迁移方案完成数据的采集
（2）直接将获取的数据，使用工具导入到oracle
如果数据提供的是txt或csv文件，那么直接使用mongoimport导入mongodb

非结构化数据采集

这一节，没多少要讲的。因为没有接触很深，但是后续是个必须的过程。使用python爬取各种数据，存储成csv或txt文件
爬取的文件，再使用mongodbimport导入mongodb中

由于要提供数据的可视化和搜索平台，建议使用ELK的技术栈，所以数据的收集使用Logstash 　

想要做数据分析，免费的growing IO。它的分析仅限于界面跳转的转化率，不能详细地分析业务数据。
我研究了一个需要埋点的产品，搞明白他们是在每个接口的调用埋点，将用户对接口的调用行为记录下来，进行分析。由于接口众多，每个接口的数据都不同。

可以充分利用hbase宽表的特性，在一行中定义一个通用的字段来标示当前行的数据类型，操作人，然后定义不同的字段来记录每一种数据。在插入数据的时候，每一行只插入当前类型和当前数据。由于hbase的宽表特性，可以容纳上百万列。可以将一家公司所有的接口访问数据都记录到一张无限大的表中，再配合辅助的用户表，就可以在各种纬度上分析用户的行为了。
分析了他们的表结构，我想用mongodb也可以做同样的事情，并且mongo比hbase好的地方在于，他入门门槛相对较低，然后在索引方面，检索的速度远比hbase那种查询要快多了。hbase只能要么按照主键范围查询，要么全表检索。为什么大的互联网公司都在推行hbase呢，这个是困扰我的地方。问了一个前腾讯员工，搞明白了两者的区别。
原因就在于写入的速度，hbase由于只维护一个主键，写入的速度要比mongodb这种要维护所有索引的数据库快多了。hbase占用两台机器能完成的事情，mongodb要占用更多的机器，每台机器按一年20000的费用，几百台下来就是一笔很大的费用。但是代价就是hbase记录下东西以后，只能事后通过全表检索或按照索引范围的方式进行整体分析，而不能对具体每个人的数据进行实时分析，更强调数据分析能力而不是实时数据查询能力，因此各有千秋吧。像用户行为分析的这种，一开始产品经理可能会具体看某一个人的数据，但是新鲜过后，只会看程序的分析结果了。因此从经济的角度出发，对于用户行为分析这种不需要实时数据的需求来说，hbase+mysql就可以用最经济的方式解决了。mongodb比较适合需要实时返回数据的大数据应用。

概要

在大数据时代，数据研发人员总是想把各类数据采集到我们的数据仓库。最典型的方案是日志收集方案： flume采集文件，转发到kafka，再使用storm写到hdfs。但是实际场景中，我们的数据源不止文件，还有mysql这类db数据。

众所周知，mysql是可以开启binlog的，也就是说我们对db的每个操作都可以通过binlog解析得到。所以我们实时解析mysql的binlog文件，即可实时获取到db的各个变更事件，就可以实时地将insert的数据，像tail日志文件一样，以规范化的形式发送到我们后端的消息中间件。

本文不会拘泥于实现细节，只会列举几个注意点，避免后续人采坑。

注意点

binlog row模式
最需要支持的点：
mysql必须支持binlog，且必须是row模式。需要关注几个问题：
1.row模式的binlog是远大于其他模式，需要注意磁盘容量
2.从其他模式binlog（如mix）改为row模式，需要断开已有mysql的连接，需要dba及相关业务开发评估可行性。
3.不需要采集的库表要独立出去，不然大量无关binlog会影响采集器的性能，堵塞通道。（需要推动业务改）
4.row模式下日志变多，还有从库解析方式发生变化，可能会造成主从不一致（状态延迟）的情况，需要dba确认

支持的语句

不支持DDL，只是inset最好，就类似文件的append。update、delete都会增加后端的处理逻辑。

事务支持

本身就是用于大数据处理的，不支持事务

字段问题

建议末尾追加字段，只用简易字段（int，string）

总结

binlog方案技术上没什么特别难点，重点还是运营的坑比较多

1. 内存模型以及分区，需要详细到每个区放什么。

栈区：

栈分为java虚拟机栈和本地方法栈

重点是Java虚拟机栈，它是线程私有的，生命周期与线程相同。

每个方法执行都会创建一个栈帧，用于存放局部变量表，操作栈，动态链接，方法出口等。每个方法从被调用，直到被执行完。对应着一个栈帧在虚拟机中从入栈到出栈的过程。

通常说的栈就是指局部变量表部分，存放编译期间可知的8种基本数据类型，及对象引用和指令地址。局部变量表是在编译期间完成分配，当进入一个方法时，这个栈中的局部变量分配内存大小是确定的。

会有两种异常StackOverFlowError和 OutOfMemoneyError。当线程请求栈深度大于虚拟机所允许的深度就会抛出StackOverFlowError错误；虚拟机栈动态扩展，当扩展无法申请到足够的内存空间时候，抛出OutOfMemoneyError。

本地方法栈为虚拟机使用到本地方法服务（native）

堆区：

堆被所有线程共享区域，在虚拟机启动时创建，唯一目的存放对象实例。

堆区是gc的主要区域，通常情况下分为两个区块年轻代和年老代。更细一点年轻代又分为Eden区最要放新创建对象，From survivor 和 To survivor 保存gc后幸存下的对象，默认情况下各自占比 8:1:1。

不过很多文章介绍分为3个区块，把方法区算着为永久代。这大概是基于Hotspot虚拟机划分，然后比如IBM j9就不存在永久代概论。不管怎么分区，都是存放对象实例。

会有异常OutOfMemoneyError

方法区：

被所有线程共享区域，用于存放已被虚拟机加载的类信息，常量，静态变量等数据。被Java虚拟机描述为堆的一个逻辑部分。习惯是也叫它永久代（permanment generation）

垃圾回收很少光顾这个区域，不过也是需要回收的，主要针对常量池回收，类型卸载。

常量池用于存放编译期生成的各种字节码和符号引用，常量池具有一定的动态性，里面可以存放编译期生成的常量；运行期间的常量也可以添加进入常量池中，比如string的intern()方法。

程序计数器：

当前线程所执行的行号指示器。通过改变计数器的值来确定下一条指令，比如循环，分支，跳转，异常处理，线程恢复等都是依赖计数器来完成。

Java虚拟机多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换能恢复到正确的位置，每条线程都需要一个独立的程序计数器，所以它是线程私有的。

唯一一块Java虚拟机没有规定任何OutofMemoryError的区块。

2. 堆里面的分区：Eden，survivalfrom to，老年代，各自的特点。

1.JVM中堆空间可以分成三个大区，新生代、老年代、永久代。

2.新生代可以划分为三个区，Eden区，两个幸存区。

在JVM运行时，可以通过配置以下参数改变整个JVM堆的配置比例

1.JVM运行时堆的大小

-Xms 堆的最小值
-Xmx 堆空间的最大值

2.新生代堆空间大小调整

　　-XX:NewSize 新生代的最小值
　　-XX:MaxNewSize 新生代的最大值
　　-XX:NewRatio 设置新生代与老年代在堆空间的大小
　　-XX:SurvivorRatio 新生代中Eden所占区域的大小

3.永久代大小调整

　-XX:MaxPermSize

4.其他

-XX:MaxTenuringThreshold, 设置将新生代对象转到老年代时需要经过多少次垃圾回收，但是仍然没有被回收

复制（Copying）算法

将内存平均分成A、B两块，算法过程：

1. 新生对象被分配到A块中未使用的内存当中。当A块的内存用完了， 把A块的存活对象对象复制到B块。
2. 清理A块所有对象。
3. 新生对象被分配的B块中未使用的内存当中。当B块的内存用完了， 把B块的存活对象对象复制到A块。
4. 清理B块所有对象。
5. goto 1。

优点：简单高效。
缺点：内存代价高，有效内存为占用内存的一半。

对复制算法进一步优化：使用Eden/S0/S1三个分区

平均分成A/B块太浪费内存，采用Eden/S0/S1三个区更合理，空间比例为Eden:S0:S1==8:1:1，有效内存（即可分配新生对象的内存）是总内存的9/10。

算法过程：

1. Eden+S0可分配新生对象；

2. 对Eden+S0进行垃圾收集，存活对象复制到S1。清理Eden+S0。一次新生代GC结束。

3. Eden+S1可分配新生对象；

4. 对Eden+S1进行垃圾收集，存活对象复制到S0。清理Eden+S1。二次新生代GC结束。

5. goto 1。

默认Eden:S0:S1=8:1:1,因此，新生代中可以使用的内存空间大小占用新生代的9/10,那么有人就会问，为什么不直接分成两个区，一个区占9/10,另一个区占1/10，

这样做的原因大概有以下几种

1.S0与S1的区间明显较小，有效新生代空间为Eden+S0/S1，因此有效空间就大，增加了内存使用率

2.有利于对象代的计算，当一个对象在S0/S1中达到设置的XX:MaxTenuringThreshold值后，会将其分到老年代中，设想一下，如果没有S0/S1,直接分成两个区，该如何计算对象经过了多少次GC还没被释放,你可能会说，在对象里加一个计数器记录经过的GC次数，或者存在一张映射表记录对象和GC次数的关系，是的，可以，但是这样的话，会扫描整个新生代中的对象, 有了S0/S1我们就可以只扫描S0/S1区了~~~

3. 对象创建方法，对象的内存分配，对象的访问定位。

#创建：

1. 类加载检查

JVM遇到一条new指令时，首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。

如果没有，那必须先执行相应的类的加载过程。

2. 对象分配内存

对象所需内存的大小在类加载完成后便完全确定（对象内存布局），为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。

根据Java堆中是否规整有两种内存的分配方式：（Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定）。

指针碰撞(Bump the pointer)

Java堆中的内存是规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，分配内存也就是把指针向空闲空间那边移动一段与内存大小相等的距离。例如：Serial、ParNew等收集器。

空闲列表(Free List)

Java堆中的内存不是规整的，已使用的内存和空闲的内存相互交错，就没有办法简单的进行指针碰撞了。虚拟机必须维护一张列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。例如：CMS这种基于Mark-Sweep算法的收集器。

3. 并发处理

对象创建在虚拟机中时非常频繁的行为，即使是仅仅修改一个指针指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。

同步

虚拟机采用CAS配上失败重试的方式保证更新操作的原子性

本地线程分配缓冲（Thread Local Allocation Buffer, TLAB）

把内存分配的动作按照线程划分为在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存（TLAB）。哪个线程要分配内存，就在哪个线程的TLAB上分配。只有TLAB用完并分配新的TLAB时，才需要同步锁定。

4. 内存空间初始化

虚拟机将分配到的内存空间都初始化为零值（不包括对象头）,如果使用了TLAB，这一工作过程也可以提前至TLAB分配时进行。

内存空间初始化保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

注意：类的成员变量可以不显示地初始化（Java虚拟机都会先自动给它初始化为默认值）。方法中的局部变量如果只负责接收一个表达式的值，可以不初始化，但是参与运算和直接输出等其它情况的局部变量需要初始化。

5. 对象设置

虚拟机对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头之中。

6. 执行init()

在上面的工作都完成之后，从虚拟机的角度看，一个新的对象已经产生了。但是从Java程序的角度看，对象的创建才刚刚开始init()方法还没有执行，所有的字段都还是零。

所以，一般来说（由字节码中是否跟随invokespecial指令所决定），执行new指令之后会接着执行init()方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算产生出来。

访问定位：句柄或者直接指针。

4. GC的两种判定方法：引用计数与引用链。
5. 在JDK1.2之前，使用的是引用计数器算法，即当这个类被加载到内存之后，就会产生方法区，堆栈、程序计数

器等一系列信息，当创建对象的时候，为这个对象在堆栈空间中分配对象，同时会产生一个引用计数器，同时引

用计数器+1，当有新的引用时，引用计数器继续+1，而当其中一个引用销毁时，引用计数器-1，当引用计数器减

为0的时候，标志着这个对象已经没有引用了，可以回收了！但是这样会有一个问题：

当我们的代码出现这样的情况时：

a)ObjA.obj=ObjB

b)ObjB.obj=ObjA

这样的代码会产生如下引用情形objA指向objB，而ObjB又指向objA，这样当其他所有的引用都消失了之后，objA

和objB还有一个相互的引用，也就是说两个对象的引用计数器各为1，而实际上这两个对象都已经没有额外的引用，已经是垃圾了。

2.根搜索算法：

根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看做一张图，从一个节点GC Root开始，寻找对

应的引用节点，找到这个节点之后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节

点则被认为是没有被饮用到的节点，即无用的节点。

目前Java中可作为GC Root的对象有：

1.虚拟机栈中引用的对象（本地变量表）

2.方法区中静态属性引用的对象

3.方法区中常量引用的对象

4.本地方法栈中引用的对象(Native对象)。

java中存在的四种引用
（1）强引用：

只要引用存在，垃圾回收器永远不会回收。

（2）软引用

非必须引用，内存溢出之前进行回收，可以通过以下代码实现

Object obj=new Object();

SoftReference