0%

慢查询日志工具mysqldumpslow

1. mysqldumpslow简介

mysql安装好后自带的, perl工具.

2. 查看命令用法:mysqldumpslow –help

[root@niewj download]# mysqldumpslow --help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

  --verbose    verbose
  --debug      debug
  --help       write this text to standard output

  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default
                al: average lock time
                ar: average rows sent
                at: average query time
                 c: count
                 l: lock time
                 r: rows sent
                 t: query time  
  -r           reverse the sort order (largest last instead of first)
  -t NUM       just show the top n queries
  -a           don't abstract all numbers to N and strings to 'S'
  -n NUM       abstract numbers with at least n digits within names
  -g PATTERN   grep: only consider stmts that include this string
  -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),
               default is '*', i.e. match all
  -i NAME      name of server instance (if using mysql.server startup script)
  -l           don't subtract lock time from total time

[root@niewj download]# 

3. mysqldumpslow参数之-(1): -v或–verbose

打印明细信息

4. mysqldumpslow参数之-(2): -s

  1. al = 平均锁定时长
  2. ar=平均返送的rows数
  3. at=平均query时长
  4. c=sql查询总数(某一条sql查询了几次)
  5. r=返送的rows总数
  6. t=query的时间总数
  7. -t N = 指定只查前N条, 相当于 limit N
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time  

排序参数:

4.1 -s at (按平均的query time)

查询平均耗时最长的慢sql:

mysqldumpslow -v -s at /var/lib/mysql/niewj-slow.log

[root@niewj download]# mysqldumpslow -v -s at  /var/lib/mysql/niewj-slow.log

Reading mysql slow query log from /var/lib/mysql/niewj-slow.log
Count: 2  Time=25.84s (51s)  Lock=0.00s (0s)  Rows=150000.0 (300000), root[root]@[121.69.51.10]
  select * from goods

Count: 3  Time=23.26s (69s)  Lock=0.00s (0s)  Rows=136666.7 (410000), root[root]@[121.69.51.10]
  select * from goods  where   id>N

Count: 6  Time=11.12s (66s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@[121.69.51.10]
  call Proc()

Count: 1  Time=11.00s (11s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@[121.69.51.10]
  select sleep(N)

Count: 1  Time=4.68s (4s)  Lock=0.00s (0s)  Rows=32262.0 (32262), root[root]@[121.69.51.10]
  select * from goods  where id>N

[root@niewj download]#

可以看到 Time=25.84s 平均时长最长, 排在最前;

阅读全文 »

1. 查看慢查询是否开启

– 查看慢查询日志开启否

show variables like 'slow_query_log';

slow_query_log OFF

2. 开启慢查询记录

– 开启慢查询日志记录

set global slow_query_log=on;

1 queries executed, 1 success, 0 errors, 0 warnings

查询:set global slow_query_log=on

共 0 行受到影响

执行耗时 : 0.008 sec
传送时间 : 0 sec
总耗时 : 0.008 sec

3. 查看慢查询日志存哪

– 查看慢查询日志存在哪里

show variables like '%slow_query_log%';

Variable_name Value
slow_query_log ON
slow_query_log_file /var/lib/mysql/niewj-slow.log

4. 多慢才算慢查询

show variables like 'long_query_time';

+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+

默认是10秒, 实验时可以改成2s:

set global long_query_time=2;

注意换个session才能查到(需要重新进入)

重新输入用户名密码:

mysql> show variables like 'long_query_time';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 2.000000 |
+-----------------+----------+
1 row in set (0.00 sec)
阅读全文 »

1. not in 和 <> 的优化–>left join

SELECT customer_id, first_name, last_name, email 
FROM customer
WHERE customer_id 
NOT IN (SELECT customer_id FROM payment);

--优化后
SELECT a.customer_id, a.first_name, a.last_name, a.email
FROM customer a
LEFT JOIN payment b ON a.customer_id=b.customer_id
WHERE b.customer_id IS NULL;

2. 大表的数据修改要分批处理

比如1000万行记录在表中要删除, 或者更新100万行记录;

优化方案: 一次只删除/删除5000条, 然后sleep几秒(暂停几秒)–>给主从同步缓冲时间;

3. 汇总查询的优化 select count(*)-> 增加汇总表

增加一个汇总表, 每天更新一次汇总值;

然后每次查询时, 汇总表+实时表(time>date(now()))即可;

SELECT COUNT(*) FROM product_comment WHERE product_id=999;

--增加汇总表 product_comment_cnt
CREATE TABLE product_comment_cnt(product_id INT, cnt INT);

--查询时:
SELECT SUM(cnt) FROM(
	SELECT cnt FROM product_comment_cnt WHERE product_id = 999
    UNION ALL
    SELECT count(*) FROM product_comment WHERE product_id = 999 AND timestr>DATE(now())
);

--
mysql> select DATE(now());
+-------------+
| DATE(now()) |
+-------------+
| 2020-09-12  |
+-------------+
1 row in set (0.01 sec)

1. JDBC获取Connection

1.1 maven依赖引入mysql-connector和h2数据库

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.21</version>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.200</version>
</dependency>

1.2 java获取连接代码-获取mysql的连接

package com.niewj;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class App {
    public static void main(String[] args) {
        String url = "jdbc:mysql://localhost:3306/test?serverTimezone=UTC";
        try {
            Connection conn = DriverManager.getConnection(url, "root", "1234");
            System.out.println(conn);
        } catch (SQLException throwables) {
            throwables.printStackTrace();
        }
    }
}

1.3 输出

com.mysql.cj.jdbc.ConnectionImpl@32b260fa

这么一段程序, 并没有写 Class.forName("com.mysql.cj.jdbc.Driver") 却能获取到mysql的数据库连接,这是什么原因呢?我们先看一下现象(呈现出来的能看到的东西):

阅读全文 »

分布式事务的一种方案:消息可靠性 + 最终一致性, 那么

如何保证消息的可靠性?

1. 消息丢失(最重要)

消息丢失:如何保证消息不丢失?

1.1. 网络原因发不出-> 记录日志+定时任务处理

比如网络原因发布出去:怎么弄? catch异常重新while(true)发几次?NoNoNo! 如果是网络原因, 很可能发不出去,

正确做法:

  1. 数据库建一个mq_message的表, 每发一条mq消息都记录到库;
  2. 定时任务扫, 状态是 “未发送成功” 的记录, 重新发送;

1.2 Broker持久化失败->生产者发送确认+失败重发

我们的消息都要设置持久化保存, 我们成功将消息发送到mq的Broker,但是broker需要将消息持久化, 然后才能进入到queue里, 这个中间mq挂了, 怎么保证消息不丢失?

Producer–>(Broker(Exchange)–>(Queue))–>Consumer

我们使用生产者发送者的确认机制: 只有发送到broker, broker持久化完成消息抵达送给队列以后, broker才会给发送者确认;这样就能保证发送成功

1.3 Consumer消费丢失->关闭自动确认, 使用手动ACK

MQ消费时宕机或消费失败?关闭消费时自动确认, 使用 手动manual ACK, 消费完确认!

2. 消息重复

2.1 消息重复的2种情形:

比如消费者消费消息, 收到了两遍

  1. consumer消费失败, 手动basicReject拒绝了, 这种是允许的;

  2. consumer消费完成,手动ACK之前突然宕机, 此时没给broker确认消息消费完成;这样, 就有可能会再发给其他的消费者,造成消息重复;

    消费成功,ack宕机,消息由 unack变为ready, 然后broker会重新发送

宗旨: 设计消费时, 做到 幂等消费

2.2 幂等消费

2.2.1 消费做状态判断

业务设置状态, 消费时做状态判断, 处理过就忽略

2.2.2 防重表:唯一标识

防重表:发送的每一个消息都有唯一标识, 处理过就忽略

3. 消息积压

消息积压会带来MQ性能的下降, 所以一定要解决消息积压的问题

3.1 消息积压的3种原因

3.1.1 消费者宕机

3.1.2 消费者本身消费能力不足

3.1.3 发送者流量太大

3.2 解决消息积压的方案

3.2.1 限制业务流量+限制发送流量(下策)

3.2.2 上线更多的消费者, 加大消费规模

3.2.2.3 若消费逻辑复杂,可以设置:先纯消费-记录数据库-离线处理

可以处理mq压力, 转移mq压力

alias和root的比较

分别使用 alias 和 root 配置访问 b.html

1.1 root->url追加到root后定位

nginx中的root配置:

location ^~ /app1/ {
    root /web;
}

# 访问: localhost/app1/b.html

b.html 在服务器的目录: /web/app1/b.html

  1. 访问时url是什么?

    localhost/app1/b.html

  2. 访问url映射到哪里?

    /app1/b.html:

    root+location 映射: /web/app1/b.html

1.2 alias->url被alias替换

nginx中的alias配置:

location ^~ /app2/ {
    alias /web;
}
b.html目录: /web/b.html
访问: localhost/app2/b.html
结论: 相当于替换

b.html 在服务器的目录: /web/b.html

  1. 访问时url是什么?

    localhost/app2/b.html (url和上面类似)

  2. 访问url映射到哪里?

    /app2/b.html:

    alias替换location 映射: /web/b.html

1.3 小结

alias:location的uri会被alias的替换;

root:location的uri会追加到root的后面连起来;

本小结源于B站freecoder同学的慷慨分享, 连接地址:

freecoder-IO多路复用select/poll/epoll介绍

1. select

image-20200910115128372

1.1 关键词描述

fds=(文件描述符集合)监听的文件描述符的数组

max=监听的fds中->最大的文件描述符值

fdset/rset=bitmap[1024]=select函数的入参rset

select函数= select(max+1, &rset, &wset, &eset, timeout )

rset=读fds; wset=写fds; eset=异常的fds,

1.2 select存在的4个问题(缺点):

1. select的rset的1024个fd的限制;

bitmap默认大小: 1024个位, 只能处理1024个fds

2. select的rset不可重用;

fdset不可重用->每次都要赋值一个新的(传参rset);

3. select的rset拷贝:用户态<–>内核态的切换开销;

4. select的rset在内核置位后返回, 检查哪些fd置1, 仍需要O(n)遍历;

2. poll

image-20200910115500446

poll引入了pollfd结构体(fd+events+revents)解决了select的前两个问题

poll函数=poll()

2.1 没有最大文件描述符数量的限制

不使用固定的1024大小的bitmap数组, 而是使用结构体数组;

2.2 pollfds结构体数组只改变revents的状态, 结构体可重用

比select优秀的是, select的fdset/rset不可重用; pollfds可以重用, 只是有数据准备好可读时, 将置位revents字段为POLLIN

2.3 问题3-用户态-内核态的切换仍存在, 没有解决;

2.4 问题4-返回后仍需要遍历结构体数组, O(n)问题仍存在;

阅读全文 »

redis学习笔记之-(6)-zset集合(排行榜-topN)

6.1 排行榜/topN基本命令

  • 加入成员: zadd key score member
  • 查询成员: zrange key start stop [withscores] 注: start = 0 end = -1 注: start/end都包含
  • 删除成员: zrem key member
  • 查看某个成员的 score: zscore key member
  • 增加某个成员的score: zincrby key increment member
  • 查看结合的size: zcard key
  • 查看topN/倒叙: zrevrange key start stop [withscores] 注: start/end都包含

6.2 案例1: 图书销量榜(books)

1. 添加成员

127.0.0.1:6379> zadd books 1 Python编程
1
127.0.0.1:6379> zadd books 2 数学之美
1
127.0.0.1:6379> zadd books 3 浪潮之巅
1
127.0.0.1:6379> zadd books 4 机器学习
1
127.0.0.1:6379> zadd books 5 深入理解Java虚拟机
1
127.0.0.1:6379> zadd books 6 鸟哥的Linux私房菜
1
127.0.0.1:6379> zadd books 7 算法(第4版)
1
127.0.0.1:6379> zadd books 8 'C Primer Plus'
1
127.0.0.1:6379> zadd books 9 "Head First Java(中文版)"
1
127.0.0.1:6379> zadd books 10 Java编程思想(第4版)
1
127.0.0.1:6379> zadd books 11 "C++ Primer中文版(第5版)"
1
127.0.0.1:6379> zadd books 12 计算机网络:自顶向下方法(原书第7版)
1
 

2. 查询所有books成员=>带分数

127.0.0.1:6379> zrange books 0 -1 withscores
Python编程
1
数学之美
2
浪潮之巅
3
机器学习
4
深入理解Java虚拟机
5
鸟哥的Linux私房菜
6
算法(第4版)
7
C Primer Plus
8
Head First Java(中文版)
9
Java编程思想(第4版)
10
C++ Primer中文版(第5版)
11
计算机网络:自顶向下方法(原书第7版)
12

3. 删除books中成员: ‘C Primer Plus’

127.0.0.1:6379> zrem books 'C Primer Plus'
1
127.0.0.1:6379> zrange books 0 -1 withscores ## 查询所有成员=>带分数
Python编程
1
数学之美
2
浪潮之巅
3
机器学习
4
深入理解Java虚拟机
5
鸟哥的Linux私房菜
6
算法(第4版)
7
Head First Java(中文版)
9
Java编程思想(第4版)
10
C++ Primer中文版(第5版)
11
计算机网络:自顶向下方法(原书第7版)
12

4. 单独查看books成员score

127.0.0.1:6379> zscore books 数学之美 ## 查看'数学之美'成员的 score
2

5. 增加books中成员排名score

127.0.0.1:6379> zincrby books 20 数学之美
22
127.0.0.1:6379> zscore books 数学之美
22

6. 查看books成员总数

127.0.0.1:6379> zcard books # 查看集合size
11

7. 查看books榜单top5

127.0.0.1:6379> zrevrange books 0 4 withscores # 逆序查看 topN => start=0 stop=4
数学之美
22
计算机网络:自顶向下方法(原书第7版)
12
C++ Primer中文版(第5版)
11
Java编程思想(第4版)
10
Head First Java(中文版)
9
127.0.0.1:6379>

6.3 案例2: 热榜新闻

2020年8月一组新闻: rank:202008

2020年9月一组新闻: rank:202009

点击新闻(增加热度), 增加score: zincrby key news:20201001 1

1. 增加新闻条目(8月): rank:202008

127.0.0.1:6379> zadd rank:202008 1 恭喜!潘玮柏晒全家照宣布结婚 
1
127.0.0.1:6379> zadd rank:202008 1 TikTok正式起诉美国政府
1
127.0.0.1:6379> zadd rank:202008 1 员工不喝领导敬酒被打耳光辱骂
1
127.0.0.1:6379> zadd rank:202008 1 上节目时遭观众现场举报
1
127.0.0.1:6379> zadd rank:202008 1 罕见!新华社3.1万字长文逐条批蓬佩奥演讲
1
127.0.0.1:6379> zadd rank:202008 1 《八佰》票房破十亿
1
127.0.0.1:6379> zadd rank:202008 1 华语影史第6位!张译主演电影票房破百亿
1
127.0.0.1:6379> zadd rank:202008 1 外媒:博尔特新冠检测呈阳性
1
127.0.0.1:6379> zadd rank:202008 1 "面对美方天价罚金 字节跳动选择和解"
1
127.0.0.1:6379> zadd rank:202008 1 1个蚂蚁金服估值相当于4个SpaceX
1

2. 查看总条数(8月)

127.0.0.1:6379> zcard rank:202008 
10

3. 用户点击新闻(8月)

127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
2
127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
3
127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
4
127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
5
127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
6
127.0.0.1:6379> zincrby rank:202008 1 TikTok正式起诉美国政府
7
127.0.0.1:6379> zincrby rank:202008 1 1个蚂蚁金服估值相当于4个SpaceX
2
127.0.0.1:6379> zincrby rank:202008 1 1个蚂蚁金服估值相当于4个SpaceX
3
127.0.0.1:6379> zincrby rank:202008 1 1个蚂蚁金服估值相当于4个SpaceX
4
127.0.0.1:6379> zincrby rank:202008 1 《八佰》票房破十亿
2
127.0.0.1:6379> zincrby rank:202008 1 《八佰》票房破十亿
3

4. 查看新闻热点前三(8月)

127.0.0.1:6379> zrevrange rank:202008 0 2
TikTok正式起诉美国政府
1个蚂蚁金服估值相当于4个SpaceX
《八佰》票房破十亿
127.0.0.1:6379> zrevrange rank:202008 0 2 withscores
TikTok正式起诉美国政府
7
1个蚂蚁金服估值相当于4个SpaceX
4
《八佰》票房破十亿
3

5. 新增一组新闻(9月) rank:202009

127.0.0.1:6379> zadd rank:202009 1 阿里巴巴合伙人胡喜正式离职
1
127.0.0.1:6379> zadd rank:202009 1 新一线城市居住报告
1
127.0.0.1:6379> zadd rank:202009 1 驴友被挂瀑布追踪
1
127.0.0.1:6379> zadd rank:202009 1 上海一公司要求员工产假期间每天手写心得
1
127.0.0.1:6379> zadd rank:202009 1 伪造清华录取书考生离家出走
1
127.0.0.1:6379> zadd rank:202009 1 女孩高考超本一线132分不敢算学费
1
127.0.0.1:6379> zadd rank:202009 1 越南美女花720万建800㎡别墅
1
127.0.0.1:6379> zadd rank:202009 1 "失联45天,95后男孩独自骑行可可西里"
1
127.0.0.1:6379> zadd rank:202009 1 消息称谷歌工程师每日工时不到6小时
1
127.0.0.1:6379> zadd rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
1
127.0.0.1:6379> zcard rank:202009
10
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
2
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
3
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
4
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
5
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
6
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
7
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
8
127.0.0.1:6379> zincrby rank:202009 1 驴友被挂瀑布追踪
9
127.0.0.1:6379> zincrby rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
2
127.0.0.1:6379> zincrby rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
3
127.0.0.1:6379> zincrby rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
4
127.0.0.1:6379> zincrby rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
5
127.0.0.1:6379> zincrby rank:202009 1 腾讯等大厂抛弃35岁员工如扔药渣
6
127.0.0.1:6379> zincrby rank:202009 1 女孩高考超本一线132分不敢算学费
2
127.0.0.1:6379> zincrby rank:202009 1 女孩高考超本一线132分不敢算学费
3
127.0.0.1:6379> zincrby rank:202009 1 女孩高考超本一线132分不敢算学费
4
127.0.0.1:6379> 

6. 9月增加一条与8月有重复的新闻

127.0.0.1:6379> zadd zrank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
1
127.0.0.1:6379> zscore zrank:202009 1个蚂蚁金服估值相当于4个SpaceX
1
127.0.0.1:6379> zincrby rank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
1
127.0.0.1:6379> zincrby rank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
2
127.0.0.1:6379> zincrby rank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
3
127.0.0.1:6379> zincrby rank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
4
127.0.0.1:6379> zincrby rank:202009 1 1个蚂蚁金服估值相当于4个SpaceX
5
127.0.0.1:6379> 

7. 查看8月和9月共同的新闻交集(相同成员score会sum加起来)

zinterstore destination numkeys key1 [key2…]

numkeys 指明: 要求交集的集合有几个

127.0.0.1:6379> zscore rank:202008 1个蚂蚁金服估值相当于4个SpaceX
4
127.0.0.1:6379> zscore rank:202009 1个蚂蚁金服估值相当于4个SpaceX
5
127.0.0.1:6379> zinterstore rank:20200809 2 rank:202008 rank:202009
1
127.0.0.1:6379> zrange rank:20200809 0 -1 # 查看所有集合内元素
1个蚂蚁金服估值相当于4个SpaceX
127.0.0.1:6379> zrange rank:20200809 0 -1 withscores # 查看所有集合内元素 withscores
1个蚂蚁金服估值相当于4个SpaceX
9
127.0.0.1:6379> 

可以看到, 两个有序集合zset求出交集, 分数会sum;

8. 查看8月和9月新闻的并集(相同成员score会sum加起来)

zunionstore destination numkeys key1 [key2…]

127.0.0.1:6379> zunionstore rank:20200809:union 2 rank:202008 rank:202009
20
127.0.0.1:6379> zrevrange rank:20200809:union 0 -1 withscores
驴友被挂瀑布追踪
9
1个蚂蚁金服估值相当于4个SpaceX
9
TikTok正式起诉美国政府
7
腾讯等大厂抛弃35岁员工如扔药渣
6
女孩高考超本一线132分不敢算学费
4
《八佰》票房破十亿
3
面对美方天价罚金 字节跳动选择和解
1
阿里巴巴合伙人胡喜正式离职
1
越南美女花720万建800㎡别墅
1
罕见!新华社3.1万字长文逐条批蓬佩奥演讲
1
消息称谷歌工程师每日工时不到6小时
1
新一线城市居住报告
1
恭喜!潘玮柏晒全家照宣布结婚
1
失联45天,95后男孩独自骑行可可西里
1
外媒:博尔特新冠检测呈阳性
1
员工不喝领导敬酒被打耳光辱骂
1
华语影史第6位!张译主演电影票房破百亿
1
伪造清华录取书考生离家出走
1
上节目时遭观众现场举报
1
上海一公司要求员工产假期间每天手写心得
1
127.0.0.1:6379>

9. 小结-zset命令

  • zadd key score member

  • zrange key start stop [withscores]

  • zrevrange key start stop [withscores]

  • zrem key member

  • zscore key member

  • zincrby key increment member

  • zcard key

  • zinterstore destination numkeys key1 [key2…]

  • zunionstore destination numkeys key1 [key2…]

    numkeys 指明: 要求交/并集的集合key有几个

redis学习笔记之-(5)-list(栈-队列-阻塞队列)

list有关的命令: lpush/rpush/lpop/rpop/brpop/blpop

5.1 栈(stack)=lpush+lpop(出入同一端)

lpush+lpop

127.0.0.1:6379> lpush juc synchronized volatile aqs thread
(integer) 4
127.0.0.1:6379> lpop juc # 最后进入的最先出列
"thread"
127.0.0.1:6379> lpop juc # 倒数第二个
"aqs"
127.0.0.1:6379> lpop juc # 倒数第三个
"volatile"
127.0.0.1:6379> 

5.2 队列(queue)=lpush+rpop(出入两端)

lpush+rpop

127.0.0.1:6379> del juc 
(integer) 1
127.0.0.1:6379> lpush juc synchronized volatile aqs thread
(integer) 4
127.0.0.1:6379> rpop juc # 先进先出
"synchronized"
127.0.0.1:6379> rpop juc # 先进先出
"volatile"
127.0.0.1:6379> rpop juc # 先进先出
"aqs"
127.0.0.1:6379> 

5.3 阻塞队列=lpush+brpop(pop阻塞)

lpush+brpop

brpop语法:

brpop key [key...] timout

timeout = 0 表示如果没有数据插入就一直阻塞;

timeout = 5 表示阻塞 5秒 如果时间到还没有值就返回null;

示例:

127.0.0.1:6379> del juc
(integer) 0
127.0.0.1:6379> lpush juc synchronized volatile aqs thread # key=juc 入队4个词
(integer) 4
127.0.0.1:6379> brpop juc 5 # 从 juc中pop一个, 如果没有元素,候时5s
1) "juc"
2) "synchronized"
127.0.0.1:6379> brpop juc 5
1) "juc"
2) "volatile"
127.0.0.1:6379> brpop juc 5
1) "juc"
2) "aqs"
127.0.0.1:6379> brpop juc 5
1) "juc"
2) "thread"
127.0.0.1:6379> brpop juc 5  # 从 juc中pop一个, 如果没有元素,候时5s后没有新push进去的, 返回null
(nil)
(5.07s)

# 此时, 另开一个终端 redis-cli, 执行了: `lpush juc semaphore`
127.0.0.1:6379> brpop juc 0  # 从 juc中pop一个, 如果没有元素, 阻塞一直等待
1) "juc"
2) "semaphore"
(15.96s)
127.0.0.1:6379> 

redis学习笔记之-(4)-set(无序不重复集合)

4.1 set集合: 抽奖

sadd key member [member...] 添加元素到集合

smembers key 列出所有member

srandmember key count 随机从key的集合中选择count个成员, 但是不移除它们;

spop key count 随机从key的集合中选择count个成员,并移除它们;

127.0.0.1:6379> sadd choujiang 1000
(integer) 1
127.0.0.1:6379> sadd choujiang 1001
(integer) 1
127.0.0.1:6379> sadd choujiang 1002
(integer) 1
127.0.0.1:6379> sadd choujiang 1003
(integer) 1
127.0.0.1:6379> sadd choujiang 2000
(integer) 1
127.0.0.1:6379> sadd choujiang 20003
(integer) 1
127.0.0.1:6379> sadd choujiang 20003
(integer) 0
127.0.0.1:6379> smembers choujiang
1) "1000"
2) "1001"
3) "1002"
4) "1003"
5) "2000"
6) "20003"
127.0.0.1:6379> srandmember choujiang 3
1) "1002"
2) "1001"
3) "20003"
127.0.0.1:6379> smembers choujiang
1) "1000"
2) "1001"
3) "1002"
4) "1003"
5) "2000"
6) "20003"
127.0.0.1:6379> spop choujiang 2
1) "2000"
2) "1001"
127.0.0.1:6379> spop choujiang 2
1) "1002"
2) "20003"
127.0.0.1:6379> smembers choujiang
1) "1000"
2) "1003"
127.0.0.1:6379> sadd choujiang 3001 3002 3004
(integer) 3
127.0.0.1:6379> smembers choujiang
1) "1000"
2) "1003"
3) "3001"
4) "3002"
5) "3004"
127.0.0.1:6379>

4.2 关注/点赞/收藏/转发/标签

key=like:niewj存储的是关注过niewj的人

sadd(关注):

user1给niewj关注的操作=sadd like:niewj user1

srem(取消关注:

user1给niewj取消关注的操作=srem like:niewj user1

smembers(展现关注的人列表):

列出给niewj关注的所有人: smembers like:niewj

scard(汇总关注人数):

汇总给niewj关注的所有人的人数: scard like:niewj

sismember(判断某人有没关注):

判断给niewj关注的人里面有没有along: sismember like:niewj along

如下:

127.0.0.1:6379> sadd like:niewj along # along给niewj关注
(integer) 1
127.0.0.1:6379> sadd like:niewj zzf # zzf给niewj关注
(integer) 1
127.0.0.1:6379> sadd like:niewj anzai # anzai给niewj关注
(integer) 1
127.0.0.1:6379> smembers like:niewj # 列出给niewj关注的人
1) "anzai"
2) "zzf"
3) "along"
127.0.0.1:6379> srem like:niewj zzf # zzf 取消了给niewj的关注
(integer) 1
127.0.0.1:6379> smembers like:niewj # 列出给niewj关注的人
1) "anzai"
2) "along"
127.0.0.1:6379> scard like:niewj # 列出给niewj关注的人的人数
(integer) 2
127.0.0.1:6379> sismember like:niewj along # 判断 along有没有给niewj关注
(integer) 1
127.0.0.1:6379> sismember like:niewj zzf # 判断 zzf有没有给niewj关注
(integer) 0

4.3 关注模型

4.3.4 共同关注:

关注了我的人: like:niewj

关注了along的人: like:along

如下:

127.0.0.1:6379> smembers like:niewj # 列出关注了niewj的人
1) "anzai"
2) "along"
127.0.0.1:6379> sadd like:niewj xupeng # 再加个关注者吧: xupeng
(integer) 1
127.0.0.1:6379> smembers like:niewj # 列出关注了niewj的人
1) "anzai"
2) "along"
3) "xupeng"
# 添加 关注 along的人
127.0.0.1:6379> sadd like:along niewj
(integer) 1
127.0.0.1:6379> sadd like:along along
(integer) 1
127.0.0.1:6379> sadd like:along xupeng
(integer) 1
127.0.0.1:6379> smembers like:along # 列出关注了 along的人:
1) "along"
2) "xupeng"
3) "niewj"
# ====> 列出 niewj和along的共同关注者:
127.0.0.1:6379> sinter like:niewj like:along
1) "along"
2) "xupeng"
127.0.0.1:6379> 

4.3.5 推荐关注(可能认识的人)

上面我们可以看到, along和xupeng都关注了 niewj和along; 这样, 我们可以从他们的关注者中找到非共同关注者, 然后给他们推荐对方的关注; 就类似于社交关系中, 给共同认识的人之外的人, 介绍他不认识的人认识;

我们先列出: 关注了along但是没有关注niewj的人:

127.0.0.1:6379> sdiff like:along like:niewj # 关注了along但是没有关注niewj的人
1) "niewj"
127.0.0.1:6379>

这样就可以推荐给 niewj, 让他 去关注 niewj;

我们再列出: 关注了niewj但是没有关注along的人:

127.0.0.1:6379> sdiff like:niewj like:along
1) "anzai"

这样就可以推荐给 anzai, 让他 去关注 along;

上面列出了交集-sinter 差集-sdiff , 还差一个并集-sunion

列出关注了niewj和along的所有人, 给他们发通知告诉他们所有人(并集)的关注名单, 让他们自己去选看自己认识不认识, 然后根据他们的选择, 手机数据 进一步确认要不要推荐他们关注;

列出两人的所有关注者:

127.0.0.1:6379> sunion like:niewj like:along # 列出两人的所有关注者
1) "anzai"
2) "along"
3) "niewj"
4) "xupeng"
127.0.0.1:6379>