Code For Colorful Life

理解生成器

参考官方文档：Generators 生成器让我们快速、简单地实现一个迭代器，而不需要创建一个实现了Iterator接口的类后，再实例化出一个对象。

一个生成器长什么样？如下

1
2
3
4
5
6
<?php
function foo() {
    ……
    yield [$someValue];
    ……
}

与一般函数的区别在于：

• 它不能return $notNULLValue（不能有，会报语法错误= =PHP Fatal error: Generators cannot return values using "return"），但可以是return;（相当于return NULL;其实当一个函数没有明确进行return时，PHP会自动为函数加入return;）
• 必须含有yield关键字（当生成器执行的时候，每次执行到yield都会中断，并且将$someValue作为返回值，如果有的话，没有则是返回NULL）。yield的具体语法见：Generator syntax
• 它会被转换为Generator类的一个对象

MySQL从5.6开始出了新的主从复制解决方案：Replication with Global Transaction Identifiers。

GTID解决的问题：

• 在整个复制集群中能够唯一的标识一个事务
• 更方便的实效转移
• 确保同一个事务只会被执行一次

GTID的限制：

• 无法使用CREATE TABLE ... SELECT statements语句
• 无法在事务中对非事务存储引擎进行更新
• 无法在事务中使用CREATE TEMPORARY TABLE
• 具体可参考：Restrictions on Replication with GTIDs

如何安全存储密码

1、使用哈希算法直接对密码进行hash

如md5(password)，sha1(password)等，这种做法在当前时代已经不安全了，因为随着“彩虹表”不断变大，如果被拖库了，用户的密码就容易被反哈希出来。国内密码学专家王小云已成功破解了md5和sha1.

SQL的注入类型有以下5种：

1. Boolean-based blind SQL injection（布尔型注入）
2. Error-based SQL injection（报错型注入）
3. UNION query SQL injection（可联合查询注入）
4. Stacked queries SQL injection（可多语句查询注入）
5. Time-based blind SQL injection（基于时间延迟注入）

前言

在MySQL <= 5.6.5，innodb_file_per_table默认为0，即InnoDB表的数据都会存储在共享表空间ibdata中，除此之外ibdata还存储着数据字典、双写缓冲区、undo log等。

当innodb_file_per_table为0时，ibdata会不断增大，有时会导致磁盘空间不足。通常是InnoDB表的数据导致的，undo log是次要原因。 因为undo log的增加通常是在事务较为繁忙的时候，且事务中做了大量的更新操作，但是undo log占用的空间却可以被重用。InnoDB的purge线程就是负责清理不需要的undo log空间以供其他的undo log使用。

那么为何InnoDB表的数据会成为ibdata增大的主要原因？因为InnoDB表的数据被delete之后的空间是无法被InnoDB重用的，需要人为干预处理= =

Storm支持的三种语义：

1. 至少一次
2. 至多一次
3. 有且仅有一次

至少一次语义的Topology写法

参考资料：Storm消息的可靠性保障 Storm提供了Acker的机制来保证数据至少被处理一次，是由编程人员决定是否使用这一特性，要使用这一特性需要：

• 在Spout emit时添加一个MsgID，那么ack和fail方法将会被调用当Tuple被正确地处理了或发生了错误。_collector.emit(new Values("field1", "field2", 3) , msgId);
• 在Bolt emit时进行锚定。_collector.emit(tuple, new Values(word));

通常情况下，只需要对单表的数据进行分页：

SELECT …… LIMIT ($CURRENT_PAGE - 1) * $PAGE_SIZE, $PAGE_SIZE ORDER BY ……

然而，在比较复杂的业务场景下，数据来自多张表（并非水平分割的表），这时就要考虑多张表的情况下，数据聚合到一起后如何分页了。

这里给出一个参考方案：

假设数据来自A、B表，分页规则按照记录的创建时间排序，再定义一个分页的状态变量time（记录时间）：

• 当获取第1页数据时：SELECT …… FROM A WHERE …… LIMIT 0, $PAGE_SIZE ORDER BY …… 和 SELECT …… FROM B WHERE …… LIMIT 0, $PAGE_SIZE ORDER BY ……，将这两份数据在代码层面合并到一起后取出前$PAGE_SIZE条记录items，并且记下第$PAGE_SIZE条记录的创建时间为time，再记下items中最后一条A记录的id为aid和最后一个B记录的id为bid；
• 当获取第2页数据时：SELECT …… FROM A WHERE …… AND created <= time AND id != aid LIMIT $PAGE_SIZE * 1, $PAGE_SIZE ORDER BY ……和SELECT …… FROM B WHERE …… AND created <= time AND id != bid LIMIT $PAGE_SIZE * 1, $PAGE_SIZE ORDER BY ……，将这两份数据在代码层面合并到一起后取出前$PAGE_SIZE条记录items，同时更新aid和bid。
• 之后数据的获取以此类推。

之所以记录aid和bid是考虑到同一张表里可能有created相同的记录，并且处于分页的边缘。