第四阶段上课也总结了一些小知识点
一:像这种父类菜单,作用只有一个,就是提供统一的版本号
十三:由于项目较多,如何统一管理?
答案:采用pom(聚合工程)的方式统一管理,打包方式POM
十四:分布式系统核心思想: 将项目的功能模块拆分到不同的tomcat服务器中,减少了系统架构的耦合性,提高了扩展性
十五:注意事项 父级项目中没有主启动类所有不需要添加build标签 有main方法时需要添加插件
MP是利用对象的方式操作数据库
十九:(以后工作)业务说明:业务是什么
KindEditor是一套开源的HTML可视化编辑器,主要用于让用户在网站上获得所见即所得编辑效果(图片),兼容IE、Firefox、Chrome、Safari、Opera等主流浏览器。
# root代表映射文件目录 #代理 服务器访问地址
定义mysql服务编号 要求必须唯一
定义mysql二进制文件名称
说明:主库重启了就会生成新的二进制文件
/主库 主要主库重启了就会生成新的二进制文件信息/
如果还有错报一个No一个YES那就
schema.xml标识的是代理和数据库之间的关联关系.
要素: 数据库IP地址/端口号/数据库名称/用户名/密码.
<!--配置第一台主机主要进行写库操作,在默认的条件下Mycat主要操作第一台主机在第一台主机中已经实现了读写分离.因为默认写操作会发往137的数据库.读的操作默认发往141.如果从节点比较忙,则主节点分担部分压力.
1代表最多的string字符串类型
5代表五种基本类型(散列(hashes),列表(lists),集合(sets),有序集合(sorted sets)和范围查询)
首先安装redis并改名
然后修改,conf配置文件(修改三处1.将IP绑定注释2.关闭保护模式3.开启后台启动)
1).AOF模式默认的条件下是关闭状态.需要手动开启.
2).AOF模式记录的是用户的操作过程. 可以实现实时持久化.保证数据不丢失.
3).AOF模式维护的持久化文件占用的空间较大.所以持久化效率不高. 并且需要定期的维护持久化文件.
RDB模式记录的是Redis内存数据快照(只保留最新数据)
AOF模式记录的是用户的操作过程. 可以实现实时持久化.保证数据不丢失.
关于redis的面试题
面试题2:公司新来了个漂亮的实习生. 去生产环境下,误操作了flushall命令,问你作为主管 如何处理?
1.关闭现有的redis服务器
一般条件下:RDB模式和AOF模式都会开启,通过save命令执行RDB持久化方式
面试题3:单线程的redis为什么快?
1)redis运行环境在内存中,纯内存的操作,所以他快
2)单线程操作,避免频繁的上下文切换
3)采用了非阻塞I/O多路复用的机制(动态感知)
redis6.0版本以前都是单线程 6.0以后支持多线程
LRU算法最好用,采用时间方法,内部是双向链表
面试题4:什么叫做定期删除+惰性删除策略
1.定期删除:redis默认每隔100ms 检查是否有过期的key,检查时随机的方式进行检查(不是检查左右的数据,因为效率太低)
问题:由于数据众多,可能抽取时没有被选中,可能出现 该数据已经到了超时时间,但是redis并没有马上删除数据
2.惰性策略:当用户获取key的时候,首先检查数据是否已经过了超时时间,如果已经超时,则删除数据
问题:由于数据众多,用户不可能将所有的内存数据都get一遍,必然会出现 需要删除的的数据一直保留在内存中的现象 占用内存资源
3.可以采取上述的内存优化手段,手动删除
尽可能均匀分片节点中的数据
由于分布式原因,导致不能获取全部节点信息,使得一个key有多个位置
是分散性另一种表现形式.表现为一个位置有多个key
1.分片主要实现了内存扩容, 没有高可用的效果.
2.哨兵主要实现了高可用效果, 没有实现内存数据的扩容. 哨兵本身没有高可用的效果.
如何优化: 内存扩容,节点实现高可用 redis集群实现.
批量修改配置文件命令:
当服务多的时侯根据脚本启动服务
一致性哈希和hash槽算法的区别 在csdn博客上关注有
不同的key有相同的结果叫做碰撞
相关面试题在day15博客上有
关于HTTPS转化问题
说明:由于浏览器出于安全性的考虑,将http协议动态的转化为https协议规范. 但是由于我们没有购买域名.所以无法使用https.应该通知谷歌浏览器禁用https的转化.
什么是跨域:只有浏览器参与了发送ajax请求 并且违反了同源策略(协议域名端口号都相同)才叫跨域
问: HTTPClient是跨域请求吗? 不是 就是远程过程调用…
1.服务启动时,会链接注册中心,将服务数据(服务名称|IP|端口)写入注册中心.
2.注册中心接收用户服务数据之后,动态维护服务列表.
3/4.消费者启动时,链接注册中心,之后将服务列表缓存到本地(缓存到消费者内存中(快)) 方便下次调用.
5.当用户调用服务消费者时.消费者根据当前服务列表的信息,进行负载均衡,挑选其中一个服务进行访问.
6.注册中心为了保证服务列表的正确性,通过心跳检测机制.实时监控所有服务生产者,如果服务器宕机,则注册中心将第一时间更新服务列表.并且全网广播 通知所有的消费者.更新服务列表.
优点:用户每次访问 几乎可以保证访问的服务器都是正确的.
步骤:上传 解压 改名字 编辑conf文件(具体参考课前资料zookeeper安装讲义)
规则:剩余存活节点的数量>N/2 N代表节点总数
1个节点 1-1>1/2 假的 一个节点不能搭建集群
2个节点 2-1>2/2 假的 两个节点不能搭建集群
3个节点 3-1>3/2 真的 集群的最小单位就是三台
4个节点 4-1>4/2 真的 大于三台都能搭建集群
为什么集群一般都是奇数台
从容灾性/经济性的角度考虑问题
答: 发现奇数台和偶数台的容灾性相同的,所以搭建奇数台更好.
将zk主机关闭,检查用户访问是否受限. 经过测试访问不受限制.
将zk集群全部关闭,检查用户访问是否受限?? 不受影响 因为消费者本地也有服务列表信息(之前缓存的)
主要处理sql拼接、排序、实体参数查询等
注意!使用的是数据库表字段,不是java属性
三:单点登录:登陆一次就不需要在登陆
用户凭证保存在cookie中 因为cookie只能看到自己家的域名
四:程序真正的执行 是由处理器(Handler处理业务)开始执行的
//数据删除 防止内存泄露七:打断点 看页面F12 查看错误
八:表单的序列化 可以简化参数的拼写
4.3 分布式架构设计方案
1).分布式架构设计 按照模块拆分 按照层级拆分
2).理解分布式/集群/高可用的概念
3).构建分布式系统的原则 如何统一管理jar包 如何统一管理工具API
4.4 京淘后端项目搭建
2).VO对象的编辑原则 调用别人的JS 必须按照要求返回JSON.
3).全局异常处理的设计.
1).跨域思想 同源策略(协议://域名:端口)
2.CORS(设定服务端数据共享 设定响应头信息)
4).伪静态思想 以.html结尾的请求
2).RPC 远程过程调用 相对本地而言 代词
5).微服务框架的调用的流程 ZK集群的选举机制/工作原理
6).Dubbo框架 1.中立的接口 2.服务生产者 3.服务器消费者
7).Dubbo负载均衡机制 1.一致性hash 2.最小访问 3.随机策略 4.轮询机制 客户端负载均衡
4.10 业务流程调用
1).基于dubbo 实现商品数据的获取
3).完成购物车功能 CRUD操作 购物车中的记录如果存在则更新数量/不存在新增购物车.
4).完成权限控制 基于拦截器
6).订单业务逻辑 表3张 为对象的引用赋值. 多张表业务操作 注意事务控制.