Redis

一.导入依赖包 <!--spring boot 默认lettuce连接redis的技术--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!--邮件--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-mail</artifactId> </dependency> <!--jdbc依赖--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <!--前端模板引擎依赖--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <!--springmvc-->

配置静态文件 在项目根目录下创建静态文件static目录,用于放置静态的文件 在settings 文件中定义静态内容 STATIC_URL = ' /static/ ' STATICFILES_DIRS = [ os.path.join(BASE_DIR, ' static ' ), ] 把静态的文件如css,js,image放入static目录中: 把当前关于注册用到的模板放到模板文件中, 在应用users中 views视图定义处理注册的请求函数,返回注册的页面: 类视图： http://python.usyiyi.cn/translate/django_182/topics/class-based-views/intro.html # 导入类视图，主要给urls from django.views.generic import View class RegisterView(View): """注册""" def get(self, request): """对应get请求方式，提供注册页面""" return render(request, "register.html", ) 在根级urls中配置到应用users的跳转路径 import users.urls url(r'^users/', include(users.urls, namespace="users")),

从今天开始我将重点分享一下Redis中的5种数据结构，今天我们学习一下第一种数据结构字符串。字符串是Redis中的最基础的数据结构。我们保存到Redis中的key，也就是键，就是字符串结构的，除此之外，我们以后学习的其它数据结构，也是在字符串的基础上设计的，可见字符串结构对于Redis是多么的重要。字符串中的值虽然是字符串但是可以保存很多种类型的如：简单的字符串、JSON、XML、二进制等等。但有一点要特别注意，就是在Redis中字符串类型的值最大只能保存512MB。 命令 设置值 set key value [EX seconds] [PX milliseconds] [NX|XX] set命令有几个非必须的选项，下面我们看一下它们具体的说明 EX seconds：为键设置秒级过期时间 PX milliseconds：为键设置毫秒级过期时间 NX：键必须不存在，才可以设置成功，用于添加 XX：键必须存在，才可以设置成功，用于更新 下面我们看一下setnx和setxx命令在实际的开发中，有什么作用呢？我们知道setnx命令只有当然key不存在的时候才能设置成功，换句话说，也就是同一个key在执行setnx命令时，只能成功一次，并且由于Redis的单线程命令处理机制，即使多个客户端同时执行setnx命令，也只人有一个客户端执行成功。所以，正是基于setnx命令的这种特性

概述 我们平时用 Redis都是处于用户层面，我们可能会不加思索地操作一个 key-value 对来方便地存取数据，感觉方便之至。但你知道这些数据在背后是如何存储以及编码的吗？ 了解清楚了这个问题，将对我们更加高效地使用 Redis具有指导意义。本文开始我们将结合 Redis源码来逐个探讨Redis五大数据类型的内部编码机制。 实验环境：Redis 4.0.10 注： 本文首发于 My Personal Blog ，欢迎光临 小站 Redis数据类型内部编码概况 对于 Redis的常用 5 种数据类型（String、Hash、List、Set、sorted set），每种数据类型都提供了 最少两种 内部的编码格式，而且每个数据类型内部编码方式的选择 对用户是完全透明的 ，Redis会根据数据量自适应地选择较优化的内部编码格式。 如果想查看某个键的内部编码格式，可以使用 OBJECT ENCODING keyname 指令来进行，比如： 127.0.0.1:6379> 127.0.0.1:6379> set foo bar OK 127.0.0.1:6379> 127.0.0.1:6379> object encoding foo // 查看某个Redis键值的编码 "embstr" 127.0.0.1:6379> 127.0.0.1:6379> Redis

Windows下安装： https://github.com/MicrosoftArchive/redis/releases zip下就解包到自定义目录下，msi就跟着步骤安装 进入安装目录下运行命令， redis-server.exe redis.windows.conf 如上图就表示成功安装 在springboot集成redis： doc: https://spring.io/projects/spring-data-redis 依赖： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> 配置文件application.properties: spring.redis.host= 127.0 . 0.1 spring.redis.port = 6379 来源： oschina 链接： https://my.oschina.net/u/4389035/blog/4126330

这是“领域驱动设计实践之路”系列的第四篇文章，从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构的思想，以实际使用场景为背景，展示了一个微服务的程序结构设计。 一、单体架构的弊端 单体结构示例(引用自互联网) 一般在业务发展的初期，整个应用涉及的功能需求较少，相对比较简单，单体架构的应用比较容易部署、测试，横向扩展也比较易实现。 然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。 下面分析下单体架构应用存在的一些弊端： 1、复杂性高 在项目初期应该有人可以做到对应用各个功能和实现了如指掌，随着业务需求的增多，各种业务流程错综复杂的揉在一起，整个系统变得庞大且复杂，以至于很少有开发者清楚每一个功能和业务流程细节。 这样会使得新业务的需求评估或者异常问题定位会占用较多的时间，同时也蕴含着未知风险。更糟糕的是，这种极度的复杂性会形成一种恶性循环，每一次更改都会使得系统变得更复杂，更难懂。 2.技术债务多 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。比如，团队必须长期使用一套相同的技术栈，很难采用新的框架和编程语言。有时候想引入一些新的工具时

1.docker search redis 2.docker pull redis 3.创建挂载的盘 mkdir -p /data/redis/conf mkdir -p /data/redis/datadir 4.将对应版本的配置文件redis.conf放入/data/redis/conf，修改属性配置成外网可访问 。 切记： #daemonize yes 否则无法启动容器 protected-mode yes 改为 no #bind 127.0.0.1 注释掉或者指定可以连接的IP # Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes

前言 前面我已经把 MySQL 的专题系列都更新完了，相信大家看了之后应该都有很大的收获（应该没有夸张吧哈哈哈哈），毕竟把 MySQL 通讲了一遍，出去面试应该也能够说比一般面试官知道得多了，在工作中性能调优的理论知识也基本上具备了（也建议大家多实践，实践出真知）。废话不多说，今天这个篇章是非专题系列，主要是给大家梳理一下关于架构方面的东西，希望大家看完之后能对服务器架构方面有一定的了解，也感谢大家一直以来的支持。 正文 架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，使系统不断进化。 那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。<br /> 分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。<br /> 合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。 <br />拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。 架构的分类 架构一般可分业务架构、应用架构、技术架构：

demo的下载地址： https://github.com/pshdhx/springboot-redis-cache-mysql 说明：我的mysql的版本是8.xx 1、必要的准备，数据库中的两张表，很简单，根据代码中的实体类建立即可。 application.properities spring.datasource.url=jdbc:mysql://localhost:3306/cache?serverTimezone=UTC spring.datasource.username=root spring.datasource.password=pshdhx #开启驼峰写法识别 #spring.datasource.driver-class-name=com.mysql.jdbc.Driver com.mysql.cj.jdbc.Driver spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver mybatis.configuration.map-underscore-to-camel-case=true logging.level.com.pshdhx.cache.mapper=debug pom.xml:已上传github； 开始使用缓存：这里要注意的是， @Cacheable(cacheNames =

Python实战社群 Java实战社群 长按识别下方二维码， 按需求添加 扫码关注添加客服 进Python社群▲ 扫码关注添加客服 进Java社群 ▲ 作者丨四猿外 来源丨四猿外（ID：si-yuanwai） 前言 当架构师大刘看到实习生小李提交的 记账流水乱序 的问题的时候，他知道没错了：这一次，大刘又要用一致性哈希这个老伙计来解决这个问题了。 嗯，一致性哈希，分布式架构师必备良药，让我们一起来尝尝它。 1. 满眼都是自己二十年前的样子，让我们从哈希开始 在 N 年前，互联网的分布式架构方兴未艾。大刘所在的公司由于业务需要，引入了一套由 IBM 团队设计的业务架构。 这套架构采用了分布式的思想，通过 RabbitMQ 的消息中间件来通信。这套架构，在当时的年代里，算是思想超前，技术少见的黑科技架构了。 但是，由于当年分布式技术落地并不广泛，有很多尚不成熟的地方。所以，这套架构在经年日久的使用中，一些问题逐渐突出。其中，最典型的问题有两个： RabbitMQ 是个单点，它一坏掉，整个系统就会全部瘫痪。 收、发消息的业务系统也是单点。任何一点出现问题，对应队列的消息要么无从消费，要么海量消息堆积。 无论哪种问题，最终是整套分布式系统都无法使用，后续处理非常麻烦。 对于 RabbitMQ 的单点问题，由于当时 RabbitMQ 的集群功能非常弱，普通模式有 queue 本身的单点问题