1. redis核心数据结构实战与高性能原理剖析

2023-10-31


本文是按照自己的理解进行笔记总结,如有不正确的地方,还望大佬多多指点纠正,勿喷。

课程内容:

1、Redis核心数据结构精讲

2、微博与微信消息流Redis实现

3、微信点赞、收藏与标签基于Redis实现

4、微博与微信朋友关注模型基于Redis实现

5、电商购物车如何用Redis实现

6、电商推荐系统如何用Redis实现

7、Redis高性能核心原理剖析、Redis 6.0多线程模型初探

redis安装步骤:https://blog.csdn.net/Ding_JunXia/article/details/131112871

1. Redis的五种数据结构

五种数据结构:

在这里插入图片描述

1.1 String

可以直接去官方文档查看使用方法,也可以使用命令行查看帮助help @String
在这里插入图片描述
1. 字符串常用操作:

set key value 存入字符串键值对
mset key value[key value…] 批量存储字符串键值对
setnx key value 存入一个不存在的字符串键值对
get key 获取一个字符串键值
mget key [key…] 批量获取字符串键值
del key [key…] 删除一个键
expire key seconds 设置一个键的过期时间(秒)

2. 原子加减

incr key 将key中存储的数字值加1
decr key 将key中存储的数字值减1
incrby key increment 将key所存储的值加上increment
decrby key decrement 将key所存储的值减去decrement

3. 应用场景

  • 单值缓存
    set key value
    get key

  • 对象缓存

    • set user:1 value(json格式数据)
    • mset user:1:name ding user:1:balance 1888
      mget user:1:name user:1:balance
  • 分布式锁

setnx product:10001 true 返回1代表获取锁成功
setnx product:10001 true 返回0代表获取锁失败
del product:10001 执行完业务释放锁
set product:10001 true ex 10 nx 防止程序意外终止导致死锁
  • 计数器
    incr article:readcount:{文章id}
    get article:readcount:{文章id}

  • web集群session共享
    spring session + redis实现session共享

  • 分布式系统全局序列号
    incrby orderId 1000 //redis批量生成序列号提升性能
    如果在分库分表中还使用数据库自带的自增id肯定是不可以的,就可以使用这个incr orderId,但是如果直接没生成一个订单,自增一个id,这对redis性能压力太大了。我们可以一次性多拿些id,incrby orderId 1000这样,拿到本机内存里面,在本机内存里面一个一个去加一,加到1000之后我再去获取。
    这里面可能会有一个小问题,第一台id当我内存加到500M,我的机器挂了怎么办呢?确实存在这种情况哈,那这不就浪费一定的id了吗?没有关系哈,大多数情况下是没有关系的,id很多,把这个步长设置的小一点,其实浪费几百个id其实关系不大。

1.2 hash

hash结构相当于一个双层的map结构(key,(key,value))

1. hash的常用操作

HSET key field value 存储一个哈希表key的键值
HSETNX key field value 存储一个不存在的哈希表key的键值
HMSET key field value [field value …] 在一个哈希表key中存储多个键值对
HGET key field 获取哈希表key对应的field键值
HMGET key field [field …] 批量获取哈希表key中多个field键值
HDEL key field [field …] 删除哈希表key中的field键值
HLEN key 返回哈希表key中field的数量
HGETALL key 返回哈希表key中所有的键值
HINCRBY key field increment 为哈希表key中field键的值加上增量increment

2. 对象缓存

HMSET user {userld}:name ding {userld}:balance 1888
HMSET user 1:name ding 1:balance 1888
HMGET user 1:name 1:balance

假设我一张user用户表可能有上万千条数据,甚至上亿,还能存在这种hash结构里面吗?
是不是不太合适啊。redis里面最怕的一个就是bigkey,大key的操作会阻塞redis,如果一条命令执行的太长,其他的命令都会被阻塞住。这样就会影响redis的并发。

3. Hash的应用场景

  • 电商购物车
    1)以用户id为key
    2)商品id为field
    3)商品数量为value

  • 购物车操作
    1)添加商品→hset cart:1001 10088 1
    2)增加数量→hincrby cart:1001 10088 1
    3)商品总数→hlen cart:1001
    4)删除商品→hdel cart:1001 10088
    5)获取购物车所有商品→hgetall cart:1001

在这里插入图片描述

4. Hash结构优缺点

  • 优点
    1)同类数据归类整合储存,方便数据管理
    2)相比string操作消耗内存与cpu更小
    3)相比string储存更节省空间

  • 缺点
    1)过期功能不能使用在field上,只能用在key上
    2)Redis集群架构下不适合大规模使用

5. redis集群架构(在这块是补充知识哈)

在这里插入图片描述

比如微博哈,他有几百T的数据肯定不是放到一个redis里面的。redis一般撑死分配10来个G的样子。对于集群来说就是把数据分片,拆成一份一份的。

1.3 列表list

1. List常用操作

LPUSH key value [value …] 将一个或多个值value插入到key列表的表头(最左边)
RPUSH key value [value …] 将一个或多个值value插入到key列表的表尾(最右边)
LPOP key 移除并返回key列表的头元素
RPOP key 移除并返回key列表的尾元素
LRANGE key start stop 返回列表key中指定区间内的元素,区间以偏移量start和stop指定
BLPOP key [key …] timeout 从key列表表头弹出一个元素,若列表中没有元素,阻塞等待timeout秒,如果timeout=0,一直阻塞等待
BRPOP key [key …] timeout 从key列表表尾弹出一个元素,若列表中没有元素,阻塞等待timeout秒,如果timeout=0,一直阻塞等待

在这里插入图片描述

2. List的应用场景

  • 常用数据结构
    Stack(栈)= LPUSH + LPOP = FILO
    在这里插入图片描述
    Queue(队列)= LPUSH + RPOP
    Blocking MQ(阻塞队列)= LPUSH + BRPOP

  • 微博和微信公号消息流
    在这里插入图片描述
    在这里插入图片描述
    带有时间线的消息流,是按照时间线排序的消息流。

  • 微博消息和微信公号消息
    我关注了邓超,孙俪等大V

  1. 邓超发微博,消息ID为10018
    LPUSH msg:{我-ID}10018
    2)孙俪发微博,消息ID为10086
    LPUSH msg:{我-ID} 10086
    3)查看最新微博消息
    LRANGE msg:{我-ID}0 4
    通过lrange查询到的消息是按照时间顺序排好序的。
    如果邓超的粉丝只有几百个上千个粉丝,意味着他发一条消息就要往这几百个或者上千个粉丝里面发消息。这种方式是可以的。假如有5000个,在发消息的时候可以有优化。我其实是可以分批发的,首先给那些在线的人先发,其他的在后台就给他们慢慢发了。
    那是邓超的粉丝实际上是有很多很多的,那怎么办呢?还是分批吗?没用的,他的粉丝那么多,在线的人肯定都特别的多。成本还是很高的,可以使用pull模式,就是我只发一份,你们上线了就从这个里面自己去拿。
    pull和push有什么区别?还有没有更好的优化策略?
    如果我关注了很多大V,每个大V都有自己的消息队列,那上线的时候就要拉去很多大V的消息,拉到本机还要排序,相对来说回避分批的那种小V要麻烦一点。

1.4 set

1. Set常用操作

SADD key member [member …] 往集合key中存入元素,元素存在则忽略,若key不存在则新建
SREM key member [member …] 从集合key中删除元素
SMEMBERS key 获取集合key中所有元素
SCARD key 获取集合key的元素个数
SISMEMBER key member 判断member元素是否存在于集合key中
SRANDMEMBER key [count] 从集合key中选出count个元素,元素不从key中删除
SPOP key [count] 从集合key中选出count个元素,元素从key中删除

2. Set运算操作

SINTER key [key …] 交集运算
SINTERSTORE destination key [key …] 将交集结果存入新集合destination中
SUNION key [key …] 并集运算
SUNIONSTORE destination key [key …] 将并集结果存入新集合destination中
SDIFF key [key …] 差集运算
SDIFFSTORE destination key [key …] 将差集结果存入新集合destination中

3. set 应用场景

  • 微信抽奖小程序
    1)点击参与抽奖加入集合
    SADD key {userlD}
    2)查看参与抽奖所有用户
    SMEMBERS key
    3)抽取count名中奖者
    SRANDMEMBER key [count]/ SPOP key [count]
    在这里插入图片描述
    在这里插入图片描述
    上面这个抽奖完之后集合里面还是不变的,但是如果我们先抽三等奖、再抽二等奖、再抽一等奖,那就需要把奖抽完之后删除该名字。
    在这里插入图片描述

  • 微信微博点赞、收藏、标签
    1)点赞
    SADD like:消息ID}{用户ID}
    2)取消点赞
    SREM like:{消息ID}{用户ID}
    3)检查用户是否点过赞
    SISMEMBER like:{消息ID}{用户ID}
    4)获取点赞的用户列表
    SMEMBERS like:消息ID}
    5)获取点赞用户数
    SCARD like:{消息ID}

  • 集合操作
    SINTER set1 set2 set3→{c}
    SUNION set1 set2 set3→{ a,b,c,d,e }
    SDIFF set1 set2 set3→{ a }
    第三行的意思是:set1减去set2与set3的交集

在这里插入图片描述

  • 集合操作实现微博微信关注模型
    1)诸葛老师关注的人:
    zhugeSet-> {guojia, xushu}
    2)杨过老师关注的人: yangguoSet–> {zhuge, baiqi,guojia, xushu}
    3)郭嘉老师关注的人: guojiaSet-> {zhuge, yangguo, baiqi, xushu, xunyu)
    4)我和杨过老师共同关注: SINTER zhugeSet yangguo2e-g
    5)我关注的人也关注他(杨过老师): SISMEMBER guojiaSet yangguoSISMEMBER xushuSet yangguo
    6)我可能认识的人: SDIFF yangguoSet zhugeSet->(zhuge,baiqi}

  • 集合操作实现电商商品筛选
    SADD brand:huawei P40
    SADD brand:xiaomi mi-10
    SADD brand:iPhone iphone12
    SADD os:android P40 mi-10
    SADD cpu:brand:intel P40 mi-10
    SADD ram:8G P40 mi-10 iphone12
    SINTER os:android cpu:brand:intel ram:8G →{P40,mi-10}

1.5 ZSet

1. ZSet常用操作

ZADD key score member [[score member]…] 往有序集合key中加入带分值元素
ZREM key member [member …] 从有序集合key中删除元素
zSCORE key member 返回有序集合key中元素member的分值
ZINCRBY key increment member 为有序集合key中元素member的分值加上increment
ZCARD key 返回有序集合key中元素个数
ZRANGE key start stop [WITHSCORES] 正序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES] 倒序获取有序集合key从start下标到stop下标的元素

2. ZSet集合操作

ZUNIONSTORE destkey numkevs key [key…]//并集计算
ZINTERSTORE destkey numkeys key [key …]//交集计算

在这里插入图片描述

3. 应用场景

  • ZSet集合操作实现排行榜
    1)点击新闻
    ZINCRBY hotNews:20190819 1守护香港
    2)展示当日排行前十
    ZREVRANGE hotNews:20190819 0 9 WITHSCORES
    3)七日搜索榜单计算
    ZUNIONSTORE hotNews:20190813-20190819 7
    hotNews:20190813 hotNews:20190814… hotNews:20190819
    4)展示七日排行前十
    ZREVRANGE hotNews:20190813-20190819 0 9 WITHSCORES

2. Redis的单线程和高性能

Redis是单线程吗?

Redis的单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的,这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能,比如持久化、异步删除、集群数据同步等,其实是由额外的线程执行的。

在这里插入图片描述

Redis 单线程为什么还能这么快?

因为它所有的数据都在内存中,所有的运算都是内存级别的运算,而且单线程避免了多线程的切换性能损耗问题。正因为Redis是单线程,所以要小心使用Redis 指令,对于那些耗时的指令(比如keys),一定要谨慎使用,一不小心就可能会导致Redis 卡顿。

Redis单线程如何出路那么多的并发客户端连接?

Redis的IO多路复用: redis利用epoll来实现IO多路复用,将连接信息和事件放到队列中,依次放到文件事件分派器,事件分派器将事件分发给事件处理器。

在这里插入图片描述

#查看redis支持的最大连接数,在redis.conf文件中可修改,# maxclients 10000
127.0.0.1:6379> CONFIG GET maxclients
	##1)"maxclients"
	##2)"10000"

3. 其他高级命令

keys:全量遍历键,用来列出所有满足特定正则字符串规则的key,当redis数据量比较大时,性能比较差,要避免使用

127.0.0.1:6379> set codehole1 a
OK
127.0.0.1:6379> set codehole2 b
OK
127.0.0.1:6379> set codehole3 c
OK
127.0.0.1:6379> set code1hole a
OK
127.0.0.1:6379> set code2hole b
OK
127.0.0.1:6379> set code3hole b
OK
127.0.0.1:6379> keys*
1) "codehole1"
2) "codehole3"
3) "codehole2"
127.0.0.1:6379> keys code*hole
1) "code3hole"
2) "code2hole"
3) "code1hole"

3.1 scan:渐进式遍历键

SCAN cursor [MATCH pattern] [CoUNT count]

scan参数提供了三个参数,第一个是cursor整数值(hash桶的索引值),第二个是key 的正则模式,第三个是一次遍历的key的数量(参考值,底层遍历的数量不一定),并不是符合条件的结果数量。第一次遍历时,cursor值为0,然后将返回结果中第一个整数值作为下一次遍历的cursor。一直遍历到返回的cursor值为0时结束。

注意:但是scan并非完美无瑕,如果在scan的过程中如果有键的变化(增加、删除、修改),那么遍历效果可能会碰到如下问题:新增的键可能没有遍历到,遍历出了重复的键等情况,也就是说scan并不能保证完整的遍历出来所有的键,这些是我们在开发时需要考虑的。

127.0.0.1:6379> scan 0 match key99* count 1000
1)“13976"(这个是下一次要扫描的游标,这个游标一直到0才结束)
2) 1) “key9911”
2)“key9974”
3 )“key9994”
4) “key9910”
5)“key9907”
6)“key9989”
7 )“key9971”

注意:但是scan并非完美无瑕, 如果在scan的过程中如果有键的变化(增加、 删除、 修改) ,那 么遍历效果可能会碰到如下问题: 新增的键可能没有遍历到, 遍历出了重复的键等情况, 也就是说 scan并不能保证完整的遍历出来所有的键, 这些是我们在开发时需要考虑的

Info:查看redis服务运行信息,分为 9 大块,每个块都有非常多的参数,这 9 个块分别是:

Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息

在这里插入图片描述

connected_clients:2 # 正在连接的客户端数量
instantaneous_ops_per_sec:789 # 每秒执行多少次指令
used_memory:929864 # Redis分配的内存总量(byte),包含redis进程内部的开销和数据占用的内存
used_memory_human:908.07K # Redis分配的内存总量(Kb,human会展示出单位)
used_memory_rss_human:2.28M # 向操作系统申请的内存大小(Mb)(这个值一般是大于used_memo
y的,因为Redis的内存分配策略会产生内存碎片)
used_memory_peak:929864 # redis的内存消耗峰值(byte)
used_memory_peak_human:908.07K # redis的内存消耗峰值(KB)
maxmemory:0 # 配置中设置的最大可使用内存值(byte),默认0,不限制
maxmemory_human:0B # 配置中设置的最大可使用内存值
maxmemory_policy:noeviction # 当达到maxmemory时的淘汰策略
127.0.0.1:6379> info
# Server
redis_version:5.0.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:bec1b87bfb6bd040
redis_mode:standalone
os:Linux 3.10.0-1160.90.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:9665
run_id:e2509cd36ff2ba601c31d05237d5cc741aa8deb7
tcp_port:6379
uptime_in_seconds:39699
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:8597002
executable:/usr/local/redis-5.0.3/src/redis-server
config_file:/usr/local/redis-5.0.3/redis.conf

# Clients
connected_clients:2
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory
used_memory:875256
used_memory_human:854.74K
used_memory_rss:10788864
used_memory_rss_human:10.29M
used_memory_peak:3905168
used_memory_peak_human:3.72M
used_memory_peak_perc:22.41%
used_memory_overhead:858808
used_memory_startup:792048
used_memory_dataset:16448
used_memory_dataset_perc:19.77%
allocator_allocated:1278976
allocator_active:1540096
allocator_resident:8687616
total_system_memory:3408482304
total_system_memory_human:3.17G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.20
allocator_frag_bytes:261120
allocator_rss_ratio:5.64
allocator_rss_bytes:7147520
rss_overhead_ratio:1.24
rss_overhead_bytes:2101248
mem_fragmentation_ratio:12.95
mem_fragmentation_bytes:9955856
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:66616
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1686286355
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:4300800
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0

# Stats
total_connections_received:52
total_commands_processed:20
instantaneous_ops_per_sec:0
total_net_input_bytes:1300673
total_net_output_bytes:5023316
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:6
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:828
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication
role:master
connected_slaves:0
master_replid:d60f3d528bece5a6d38c1d5e1f38ab6f7c098b67
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:22.465098
used_cpu_user:13.196395
used_cpu_sys_children:0.008807
used_cpu_user_children:0.000000

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=2,expires=0,avg_ttl=0
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

1. redis核心数据结构实战与高性能原理剖析 的相关文章

随机推荐

  • MySQL学习总结--WAL日志

    MySQL学习总结 WAL日志 WAL redo log VS binlog 日志的两阶段提交 组提交机制 group commit redo log 重做日志 binlog 归档日志 binlog 的三种格式对比 WAL 导致了内存脏页
  • JS中用window.open()方式打开,使新页面全屏、居中的代码

    window open 的介绍 1 基本语法 window open pageURL name parameters 2 各项参数 其中yes no也可使用1 0 pixel value为具体的数值 单位象素 参数 取值范围 说明 alwa
  • 基于亚马逊云科技无服务器服务快速搭建电商平台——性能篇

    使用 Serverless 构建独立站的优势 在传统架构模式下 如果需要进行电商大促需要提前预置计算资源以支撑高并发访问 会造成计算资源浪费并且增加运维工作量 本文介绍一种新的部署方式 将 WordPress 和 WooCommerce 部
  • java实现“两数之和”

    java代码如下 import java util Arrays import java util HashMap import java util Map import java util Scanner 问题 两数之和 给定一个数组 和
  • 凸优化系列——约束优化问题

    1 KKT条件 局部最优解 全局最优解 严格最优解 注意几类非光滑函数的转化 约束优化最优解的特征 最优解的一阶必要条件 Karush Kuhn Tucker KKT条件
  • CentOS 7 源码制作openssh 9.4p1 rpm包 —— 筑梦之路

    参考之前的博客 centos 7 制作openssh8 7 8 8 8 9 9 0 9 1 9 2 9 3 p1 rpm包升级 筑梦之路 openssh rpm包 筑梦之路的博客 CSDN博客 需要说明的是9 4版本必须要openssl 1
  • Windows2003系统漏洞提权复现

    操作系统 Microsoft Windows Server 2003 Web服务器 IIS V6 0 第一步 将大马文件上传至服务器根目录 第二步 访问大马文件 进入大马的控制界面 第三步 查看漏洞补丁信息 第四步 上传漏洞工具 将提权工具
  • 在Vue2项目中使用Vant组件库

    Vant 2 Mobile UI Components built on Vuehttps vant contrib gitee io vant v2 zh CN home1 安装vant包 Vue2项目下必须这么写 不能直接写npm i
  • MySQL 排序

    排序数据 1 排序规则 使用ORDER BY 字句排序 在其后面加所需字段 ASC ascend 升序 DESC descend 降序 ORDER BY 字句在SELECT语句的结尾 注意 数据库中默认按照先后添加顺序存储数据 在查询时 也
  • python中的sort的用法

    一 sort的两种用法 1 a sort 对原列表进行原址排序 原址排序的意思是原列表被改变了 排序的规则 数字 字符串按照ASCII 中文按照unicode从小到大排序 a 2 3 6 7 1 a sort print a 1 2 3 6
  • chrony系统授时时,几条重要命令输出信息的含义

    原文 https docs fedoraproject org en US Fedora 18 html System Administrators Guide sect Checking if chrony is synchronized
  • 确定你的public继承塑模出is-a关系——条款32

    如果你令class D Derived 以public形式继承class B Base 你便是告诉C 编译器 以及你的代码读者 说 每一个类型为D的对象同时也是一个类型为B的对象 反之不成立 你的意识是B比D表现出更一般化的概念 而D比B表
  • 开关电源-电容

    电子元器件 电容 1 电容是电路中重要的元件 种类多 用途广 主要有插件类和贴片类两种 2 电容主要特性参数 标称容量 耐压 误差 温度 2 1电容容量常用单位有微法 uF 纳法 nF 皮法 pF 单位换算 luF 103nF 106pF
  • 【数模】编码的传输问题 Huffman算法编程实现(matlab)

    编码的传输问题 利用Huffman算法编程实现以下问题 已知字母A B C D E F出现的概率 字母 概率 A 35 B 10 C 20 D 10 E 20 F 5 哈夫曼编码基础知识复习 哈夫曼编码 Huffman Coding 又称霍
  • Tensorflow框架(张量、计算图、会话)

    张量 计算图 会话 人工智能实践 Tensorflow笔记 Tensorflow框架 张量 计算图 会话 基于Tensorflow的NN 神经网络 用张量表示数据 用计算图搭建神经网络 用会话执行计算图 优化线上的权重 参数 得到模型 张量
  • 抓包工具fiddler不抓取火狐浏览器的数据

    fiddler可以抓到google浏览器的包 但是抓不到Firefox浏览器的包 火狐浏览器版本79 0 64 位 fiddler 4 亲测好使 操作步骤 打开Fiddler gt 菜单栏 Tools gt Options gt Conne
  • sdf转smi

    from rdkit import Chem smi Chem MolToSmiles Chem SDMolSupplier sdf path 0
  • 全局组件和局部组件

    1 全局组件和局部组件的区别 全局组件 只需要在main js中导入一次 整个项目都可以直接使用 在main js中导入 局部组件 用一次 导一次 在用到的地方导入 2 局部组件导入步骤 3部曲 1 导入子组件 import Registe
  • 基于Flask框架的python微博数据分析

    Python 微博数据 博文 分析 项目简介 后端采用Flask框架搭建 通过移动端接口获取数据 数据清洗后采用jieba进行词法分析 通过WordCloud制作词云展示 数据的可视化在以后的版本中会细化 版本V0 0 1功能 能够获取用户
  • 1. redis核心数据结构实战与高性能原理剖析

    分布式缓存技术Redis 1 Redis的五种数据结构 1 1 String 1 2 hash 1 3 列表list 1 4 set 1 5 ZSet 2 Redis的单线程和高性能 3 其他高级命令 3 1 scan 渐进式遍历键 本文是