tag 标签: 架构

相关帖子
相关博文
  • 热度 17
    2021-4-8 15:12
    4261 次阅读|
    0 个评论
    Power Delivery的源起与规格(一)
    浅谈Power Delivery起源与规格 过往产品的充电装置多由各家厂牌使用各自的接口,导致装置汰换时将造成许多浪费。由于USB的普及,市面大部分的产品都透过此接口传输数据,进而促使人们欲提升USB供电能力的想法。过去即使透过USB Battery Charging 1.2 (BC1.2) 方式最多也只能提供7.5W (5V 1.5A),则电子产品需要较长的时间来充电。 USB-IF (USB Implementers Forum) 于2012年发表第一版USB Power Delivery规范 (USB Power Delivery Specification Revision 1.0, Version 1.0),其规格使供电能力大幅提升到最高100W (20V 5A)。随着更多功能的加入,规范不断更新,现已来到USB Power Delivery Specification Revision 3.0 (后续以PD及PD Spec简称)。PD认证信息:https://graniteriverlabs.com.cn/usb-pd/ 随发展越来越成熟,Type-C接口渐渐成为市面上的主流,且多数产品支持PD,这些产品使用Configuration Channel (CC) pin传输PD沟通的讯息与协议,透过VBUS脚位供电。以下将从Type-C架构简介开始,逐步了解PD概念。 Type-C 架构 (Source/Sink Detection) 依 供电端 与 耗电端 区分Power角色,广义可分为下列三种: 对接的两端透过CC与VBUS侦测是否有合适的装置连接上: 1. Source: 监测CC pin电压,当Source 侦测到CC pin上Rd,表示接上Sink,则Source会在VBUS输出5V 2. Sink: 侦测VBUS,有5V时可知此时连接上Source PD沟通前,Type-C连接示意图 (图一,取自Type-C Cable and Connector Spec) PD 架构 以Source端举例说明,Device Policy Manager主要负责监控装置整体使用状况,工作包含:控制Power Source和USB-C Port Control模块,并与Policy Engine合作以调节电源分配,每个埠根据被分配到的资源与其对接的装置协议。USB-C Control则控制前一小节所述Source/Sink Detection部分,之后PD行为的控制由Physical Layer (PHY Layer)、Protocol、Policy Engine三部分共同合作,最后由Power Source透过VBUS供电给对方。 USB PD 架构示意图 (图二,取自PD3.0 Spec) Policy Engine 向上提供Device Policy Manager个别埠的状态,使Policy Manager可以实时整合与更新装置状态并重新调配资源予每个埠。 向下依据政策判断如何发送与响应收到的PD讯息,并指示Protocol Layer建构讯息。 Protocol Layer 传送讯息端: 接收Policy Engine的指示建构所需讯息交给PHY Layer,并藉由对方回传GoodCRC确认讯息有正确送出,否则视为传送失败,适用重新发送(Retry)机制。 接收讯息端: 收到PHY Layer传来的讯息,解读该讯息并将信息向上呈报给Policy Engine,在做相对响应前,先建构GoodCRC讯息让PHY回送给对方,表示讯息已正确收到并解读。 同时装置双方的Protocol Layer需各自计算对方是否在要求时间内有正确的响应 (Timer check)。 若以上确认内容有侦测到任何错误,任一方的Protocol Layer可发起 Reset机制 重整状态: PHY Layer 把Protocol层送来的讯息再加工,加上以4b5b方式编码的SOP*、CRC、EOP以及Preamble,组成一完整的讯息,透过CC以BMC方式传送给对方。 PD 讯息格式示意图 (图三,取自PD3.0 Spec) 反之,收到讯息时,PHY要先验证收到的讯息CRC,若正确就将讯息向上回传给接收端的Protocol Layer。 PHY Layer传送讯息流程示意图 (图四,取自PD3.0 Spec) 下图以Source Capabilities讯息为例,简单表示上述内容中的传送端、接收端,以及讯息的传送流程: (图五) 由上述可以看到对接的两端装置PD讯息都靠同一条路线 (CC) 传送,为避免两端同时传讯息,Source的Protocol有Collision Avoidance机制可以透过指示PHY控制Rp设定,告诉Sink当下是否可以只针对Source讯息响应。 下期专栏,将讲解Power Delivery协议规范,请持续关注! USB、USB-C、USB Type-C®和USB-IF是USB Implementers Forum的注册商标 免责声明 本资讯仅为便于参照而提供。本资讯不是且不应视为 USB Implementers Forum (USB-IF) 之正式通讯。USB-IF 之正式通讯可于其网站 usb.org 取得,或直接自 USB-IF 取得。 参考文献 USB Type-C® Cable and Connector Specification Revision 2.0 USB Power Delivery Specification Revision 1.0 Version 1.2 USB Power Delivery Specification Revision 2.0 Version 1.3 USB Power Delivery Specification Revision 3.0 Version 2.0 Granite River Labs USB Compliance Test https://graniteriverlabs.com.cn/usb-compliance/ 原创声明 作者 GRL台湾测试工程师 张文馨 Cindy Chang 毕业于国立成功大学材料所。具三年多的Power Delivery相关测试经验,熟悉Thunderbolt PD、USB-IF PD Compliance、QC (Qualcomm Quick Charge) 等测试规范。目前在GRL台湾负责PD测试,乐于协助客户PD方面的问题,以顺利取得认证。
  • 热度 8
    2020-12-18 17:10
    6055 次阅读|
    2 个评论
    USB4™ 全方位技术剖析
    原创声明 作者: GRL 实验室 林志徽 Caspar Lin USB4™ 介绍 USB4 全名为 Universal Serial Bus Generation 4 。 USB 这个接口在 1996 年发布 USB 1.0 规格 , 传输速度支持低速 1.5 Mbps 与全速 12 Mbps ,以及之后陆续发表支持速度 480 Mbps 、 5Gbps 、 10Gbps 、 20Gbps 等,并在 2019 年 9 月发布最新一代 USB4 规格,支持 20Gbps 与 40 Gbps 。 USB 接口演进及相对应的 logo ,请参考表一。 ( 表一 ) USB4™ 新功能 3 个重点 1. USB4 只采用 USB Type-C 连接器。 USB4 讯号采双信道传输。而过去的连接器如 USB Type-A 或 Micro-B ,仅支持单通道传输,无法支持 USB4。 2. USB 传输速度最快支持 40G (20Gbps x2) ,并可同时传送 DisplayPort 影音。旨在将多种协议组合到单个物理接口,可以动态共享 USB4 架构的整体速度和性能。 3. 向下兼容 USB 2.0 与 USB 3.2 及支持 Thunderbolt 3 。 USB4™ 连接器与线缆 3 个重点 1. USB4 只采用 USB Type-C 连接器。 2. USB4 Cable 被动线缆,可支持的被动线缆长度由 USB 3.2 Gen2 的 1 公尺,降为 USB4 Gen3 的 0.8 公尺。 3. 若需较长的线缆,如连接大尺寸屏幕,或是 VR 应用,可使用主动式线缆。 USB4 主动式线缆为含有 Repeater 组件(如 Re-timer , Re-driver 等主动组件)的线缆,及光纤线缆等。可支持的主动式线缆长度最长为 5 公尺 , 而光纤线缆最长可以支持 50 公尺。 USB4 架构上 3 个重点 USB4 主要构成组件有 Router ( 路由器 ) , Adapter ( 适配器 ) ,以及 TMU (Time Management Unit ,时间管理单元 ) 。 1. Router 是 USB4 的一个主要建构模块, Router 将隧道协议转换成 USB4 封包传送,并透过 TMU 来作时间同步。主要由 USB Host 内建的 Connection Manager 来侦测及管理。 2. Adapter 是内建在 Router 里,主要功能为 Router 与外部组件沟通的媒介,进行协议转换。例如 USB4 Host 在传输 USB3 数据(如下图),由内部 USB3 Host 透过 USB3 Adapter 进行协议封装成 USB4 Tunneled Packet 。一个 Router 内部最多可以支持 64 个 Adapter 。 3. TMU 是内建在 Router 里,使用分布式时间管理单元( TMU ),在 Router 间做时间同步。 USB4 依功能层级分为 5 种 1. Protocol Adapter Layer: 负责 USB4 与不同协议间进行对应 . 并把不同协议封装成 Tunneled Packet 在 USB4 介面内传递。 2. Configuration Layer: 负责处理由 Connection manager 传送来的 Control Packets ,并附加路径中对应的地址 (address) ,确保其可靠的传送机制。 3. Transport Layer: 定义封包格式、路径、流量控制与时序控制,并产生 link management Packets 以提供时间同步封包、流量控制封包等。 4. Logical Layer: 负责建立 2 个装置之间的 USB4 链接,提供数据传送与接收、编码与译码,电源管理,错误侦测及复原机制,并且透过 Sideband Channel 进行通道初始化的沟通,包括速度及双信道沟通。 5. Electrical Layer: 定义 USB4 电气讯号的特性,如电压、抖动,编码等。 如下图,以 USB3 Tunneling 为例, USB4 Host 透过 USB3 Protocol Adaptor ,将 USB3 Protocol 经 USB4 Transport Layer 、 USB4 Logic Layer 、 USB4 Electrical Layer 转 USB4 Link 传送到 USB4 Hub Electrical Layer 。再依下图顺序进行 一连串 USB3/USB4 转换,将讯号传送到 USB4 Device 。 USB3 隧道协定 USB4 讯号由 PCIe 、 USB3 及 DisplayPort 隧道协议组成。此篇幅单就 USB3 隧道协议讲解。 USB3 隧道协议,指的是将原始 USB3 封包经由 Protocol Adapter Layer 封装成 Tunneled 封包 , 藉由以下的图片可以清楚知道 , 红色部分 是 USB3 的封包而蓝色部分是 Tunneled 封包 , UFP 与 DFP 之间会使用 Physical Layer 传输。 Note: UFP: Upstream Facing Port , DFP: Downstream Facing Port USB4 的产品有 4 种类型 1. USB4 Host: 产品有一个以上 DFP 。没有任何的 UFP 。 2. USB4 Hub: 产品有一个 UFP ,并且有一个或多个 DFP 。 3. USB4-Based Dock: 产品有一个 UFP ,并且有一个或多个 DFP ,且产品内还有其他 device 的功能,如储存装置或网络功能。 4. USB4 Device: 产品有一个 UFP ,没有任何的 DFP 。 Note: UFP: Upstream Facing Port , DFP: Downstream Facing Port USB4 支持的隧道协议 依据规格,对 Host/ Hub/Dock/Device 必须支持的隧道协议有不同要求,如下图,打 “V ” 为必须支持,其余则是可选择支持与否。 例如 USB Host 必须支持 USB3 、 DisplayPort 与 Host-to-Host Tunneling ,可以不支持 PCI Express 与 TBT3 Tunneling 。 USB4 支援的传输速率 USB4 支援 USB4 Gen2 的 20Gbps 及 USB4 Gen3 的 40Gbps 速度,是不是宣告支持 USB4 就一定要支持这两个速度? • 对 USB4 Hub 与 USB4-Based Dock 来说,必须同时支持 20Gbps 及 40Gbps 。 • 对 USB4 Host 与 USB4 Device 来说,可以只支持 20Gbps 。( 40Gbps 可列为额外支持,非必要支持速度)。 结论 USB4 传输速率提升到 40 Gbps ,并且可以动态分享带宽 , 当使用一条 USB Type-C 连接线就可以兼容于市面上 Thunderbolt 3 和 Display Port 产品,对于消费者来说是一个更加便利的界面。但对于产品开发者来说, USB4 是一个比较大的挑战,除了产品设计和以往 USB3 的产品在架构上的差异,加上高频信号在 PCB 及连接器上的衰 减,须更关注高频阻抗匹配,在开发阶段确保传输的信号质量。 免责声明 本信息仅为便于参照而提供。本信息不是且不应视为 USB Implementers Forum (USB-IF) 之正式通讯。 USB-IF 之正式通讯可于其网站 usb.org 取 得,或直接自 USB-IF 取得。 参考文献: Universal Serial Bus 4 (USB4™) Specification Version 1.0 August, 2019
  • 热度 24
    2013-6-8 16:19
    980 次阅读|
    0 个评论
    嵌入式Linux架构和开发实践培训 课程简介: 对开发者而言, Linux 本身因其庞大复杂性导致学习确实有一定的难度,但这并不是掌握不了的主要原因。 Linux Torvalds 倡导 Linux 开发时要“接口定义合理,代码风格一致”和“一次做一件事情,做到完美”   ,旨在针对一方面是前辈级别的 Linux 开发者尤其是内核开发者对 Linux 的掌握越来越出神入化而另一方面对 Linux 的初学者而言门槛确越来越高的尴尬境地; Linux 的学习尤其是 Linux Kernel 的学习的门槛确实很高,究其核心原因: 开发者在学习的时候没有很好的掌握 Linux 的架构和设计的原则和灵魂; 缺乏有效的学习方法; 根据自己多年的经验和领悟,家林设计出了一套行之有效的学习课程,按照该课程内容掌握 Linux 必然会事半功倍的轻松掌握 Linux 开发的精髓。 中国电子标准协会 http://www.ways.org.cn 课程目标: 本课程旨在协助工程师快速领悟Linux架构和设计的核心精髓,在此基础上掌握Linux设计和实现的细节,从而迈开Linux开发尤其是Linux Kernel的高手之旅的第一步。 培训对象:          能看懂C语言代码;          具有计算机理论基础的并想从事于Linux开发;     时间 內  容 备注 第一天 第1个主题:Linux开发的核心要素 1,1 不同的Linux版本 1,2 源代码的获取与提交 1,3 编译内核 1,4 内核开发最佳实践步骤   第2个主题:进程管理和调度 2,1 进程的创建和终结; 2.2 再谈Fork机制; 2.3 线程; 2.4 进程调度的策略和算法; 2.4 抢占;   第3个主题:中断 3.1 注册和编写中断; 3.2 中断控制; 3.3 软中断; 第4主题:内核同步 4.1 锁; 4.2 内核同步策略;   第5主题:内存管理 5.1  kmalloc与vmalloc; 5.2  内存映射;   第6个主题: 虚拟文件系统 6.1文件系统抽象层; 6.2 VFS及其数据结构; 6.3 超级快、索引节点和目录、文件对象; 6.4 仿制对象;     时间 內  容 备注                         第二天 第7个主题: I/O 7.1 块设备和bio结构体; 7.2 I/O调度程序;   第8个主题:地址空间 8.1 内存描述符和内存区域; 8.2 如何操作内存区域? 8.3 深入思考mmap;   第9个主题:页面的高速缓存 9.1 告诉缓存的方式和实现 9.2 pdflush   第10个主题:kobject与sysfs 10.1  kobject; 10.2  sysfs;   第11个主题:调试 11.1  printk; 11.2  内核调试配置; 11.3  gdb、kgdb、kdb;   第12个主题:移植性 12.1  字长和数据类型; 12.2  数据对齐与字节顺序; 12.3  页长度; 12.4  SMP、处理器排序、内核抢占、内存;                  
  • 热度 19
    2013-6-8 16:12
    921 次阅读|
    0 个评论
    FPGA架构和开发实践 培训 课程简介: 从 FPGA 的架构设计入手,然后分析 FPGA 经典的开发流程,到时序分析,最后以仿真实验和两个实战实战介绍,是入门的经典课程 课程目标: 本课程旨在协助工程师快速领悟FPGA架构和设计的核心精髓,在此基础上掌握FPGA开发实战,从而建立扎实的FPGA开发基础。   中国电子标准协会 http://www.ways.org.cn   时间 內  容 备注 第一天 第1个主题:FPGA的架构设计 1,1 状态机设计; 1,2 复位设计; 1,3 FPGA的设计思想   第2个主题:FPGA的开发流程 2,1 FPGA再认识; 2.2 FPGA的开发流程;   第3个主题:时序分析 3.1 时序分析核心; 3.2 基于ISE的时序约束; 3.3 基于TimeQuest的时序分析; 第4主题:仿真测试 4.1 测试用例设计; 4.2 测试用例实战;   第5主题:实验 5.1  基于EPM240的实验; 5.2  基于EP1C3的实验;          
  • 热度 14
    2013-6-8 14:57
    934 次阅读|
    0 个评论
      本课程专为摩托罗拉移动而定制,属于Android架构与实战技术基础级别的内容;     中国电子标准协会 http://www.ways.org.cn 培训内容     第一天 第1个主题:Android中启动一个新的应用程序揭秘(60分钟) 1 当我们触摸Android屏幕中Launcher上的一个应用程序的图标的时候到底发生怎样的调用过程? 2 应用程序的执行入口到底在哪里? 3 一个新的Android应用程序的进程到底是怎么产生的?   第2个主题:HAL基本设计和接口(60分钟) 1 hw_module_t与hw_device_t 2 C语言如何实现继承来满足HAL Stub的设计目的?包括内存结构分析和代码风格讨论等 3 如何避免HAL Stub实现时的Dirty Code?   第3个主题:Android中的NDK编程(30分钟) 1 NDK与JNI关系揭秘 2 NDK开发的流程 3 采用NDK方式开发出的程序安装和运行的内幕 4 NDK中的Java与C/C++相互调用 5 NDK中的多线程编程 6 关于Android软件开发的标准化和可替换性揭秘   第4个主题:SystemServer与Framework中的Service(60分钟) 1 Zygote与SystemServer 2 SystemServer开启Java世界的过程揭秘 3 Android Service和Native Service是如何关联起来的? 4 Android Service与ServiceManager 5 如何把自己的服务加入到ServiceManager中?   第5个主题:Android框架移植时的事件驱动机制(60分钟) 1 Android Service是如何应对硬件阻塞的? 2 开辟新的子线程并不断的poll 3 Listener注册 4 Callback 5 Application Framework中的Handler、Message、Looper、MessageQueue 6 事件驱动机制实例     第6个主题:Android Application Framwork和App的关系(30分钟) 1 Framework和App的具体关系是什么? 2 Framework和App的交互过程? 3 Framework如何掌控App的? 4 Framework与Android的四大组件;   第7个主题: Handler、Looper、Message、MessageQueue(60分钟) 1. Android的事件驱动模型 2. Looper、MessageQueue、Hanlder、Message等源码深度剖析 3. Looper、MessageQueue、Hanlder、Message及多线程实战案例 4. Native/Java层的Looper/Handler的原理和交互            
相关资源
  • 所需E币: 0
    时间: 2024-4-22 17:00
    大小: 2.4KB
    一.什么是微前端“微前端架构”就是构建基于微服务的前端应用架构。其思想是将前端应用切分为一系列可以单独部署的松耦合的应用,然后将这些应用组装起来创建单个面向用户的应用程序。二.微前端的优势降低代码耦合独立开发、独立部署增量升级:微前端是一种非常好的实施渐进式重构的手段和策略独立运行时,每个微应用之间状态隔离,运行时状态不共享团队可以按照业务垂直拆分更高效三、微前端是一种前端架构模式,它将Web应用程序拆分为一组小型、可独立开发和部署的模块,每个模块可以由不同的团队开发和维护。这种模块化的架构可以帮助开发团队降低Web应用程序的规模和复杂度,从而提高应用程序的可维护性和可扩展性。微前端的概念最早由ThoughtWorks公司的技术总监CamJackson在2016年提出。他认为,微前端可以帮助团队将大型Web应用程序拆分为小型模块,从而更好地满足不同业务需求,提高应用程序的可维护性和可扩展性。自此之后,微前端逐渐成为了一种前端技术趋势,得到了越来越多的关注和支持。微前端的背景源于大型Web应用程序的发展和演进。随着Web应用程序的规模和复杂度的不断增加,前端开发团队面临越来越多的挑战,例如开发和维护难度大、代码耦合度高、性能问题等等。微前端通过将Web应用程序拆分为小型、可独立开发和部署的模块,从而降低了这些挑战的难度,提高了Web应用程序的可维护性和可扩展性。四、微前端的挑战包括:技术复杂度:微前端需要使用一些新的技术和工具来实现模块化开发、模块间通信和集成等功能,需要开发团队具备一定的技术实力和经验。项目规模限制:微前端适用于大型Web应用程序,但对于小型应用程序,可能会带来过度的复杂度和不必要的开销。性能问题:微前端需要在运行时动态加载模块,可能会影响应用程序的性能和响应速度,需要通过一些优化措施来解决。跨域问题:微前端需要在不同的域名下部署不同的模块,可能会带来跨域问题,需要通过一些跨域解决方案来解决。五、micro模块micro-app是京东零售推出的一款微前端框架,它基于类WebComponent进行渲染,从组件化的思维实现微前端,旨在降低上手难度、提升工作效率。它是目前接入微前端成本最低的框架,并且提供了JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。MicroApp借鉴了WebComponent的思想,通过CustomElement结合自定义的ShadowDom,将微前端封装成一个类WebComponent组件,实现微前端的组件化渲染。在此基础上,通过实现JS隔离、样式隔离、路由隔离,降低子应用的接入成本,子应用只需设置允许跨域请求,不需要改动任何代码即可接入微前端,使用方式和iframe几乎一致,但却没有iframe存在的问题。用于给应用赋能微前端,使其成为主应用,能够内部接入子应用。入口index.js:用于和主应用初始化接入;appConfigs.js:用于配置要接入子应用的相关信息;commonApi.js:公用的接口函数,透传给子应用使用;appTemplate.vue:子应用展示容器,类似于iframe效果;router.js:主应用中处理过后的子应用路由地址,最后合并接入到主应用路由文件。六、集成与部署策略在微前端架构中,集成与部署策略是至关重要的。以下是一些常见的集成与部署策略:构建时集成:在主应用的构建过程中,将微应用的代码打包到主应用的代码中。这种方式适用于微应用较少且更新不频繁的情况。运行时集成:主应用在运行时动态加载微应用的代码。这种方式可以实现微应用的独立部署和按需加载,适用于微应用较多且更新频繁的情况。独立部署:每个微应用都可以独立部署,主应用通过配置来管理微应用的版本和加载地址。这种方式可以实现微应用的并行开发和持续集成/持续部署(CI/CD),提高开发效率。容器化部署:使用Docker等容器化技术将每个微应用打包成容器进行部署。这种方式可以实现微应用的环境隔离和弹性扩展。
  • 所需E币: 0
    时间: 2024-3-5 10:30
    大小: 45.37MB
    上传者: 随遇而安1992
    本书通过梳理大型网站技术发展历程,剖析大型网站技术架构模式,深入讲述大型互联网架构设计的核心原理,并通过一组典型网站技术架构设计案例,为读者呈现一幅包括技术选型、架构设计、性能优化、Web安全、系统发布、运维监控等在内的大型网站开发全景视图。本书不仅适用于指导网站工程师、架构师进行网站技术架构设计,也可用于指导产品经理、项目经理、测试运维人员等了解网站技术架构的基础概念;还可供包括企业系统开发人员在内的各类软件开发从业人员借鉴,了解大型网站的解决方案和开发理念。
  • 所需E币: 0
    时间: 2023-12-14 10:32
    大小: 2.41KB
    上传者: 开心就很好了
    今天给大家讲讲关于多级网关与多级缓存架构的相关知识,在文章里面,我将从0到1带着大家构建基础服务接口,通过层层递进优化服务,使得服务具备多级缓存的特性,并融合OpenResty拓展一个强大的多级网关+多级缓存的技术架构。以下就是代码实战展示:引入springboot3的maven依赖,本质上作为pom引入,直接管理他的版本号,后续用到啥组件直接拿来即用:<dependencies>  <!--引入SpringBoot依赖-->  <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter</artifactId>  </dependency>  <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-web</artifactId>  </dependency>  <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-configuration-processor</artifactId>  </dependency>  <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-aop</artifactId>  </dependency>  <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-jdbc</artifactId>  </dependency></dependencies>dependencyManagement依赖管理全代码依赖配置如下:<!--  使用dependencyManagement的目的是为了保证当前父工程的干净,  也就是说父工程他只负责对依赖(坐标)的管理,以及依赖的版本管理,而不会去引入额外的jar依赖  如此一来,父工程的职责就相当的单一了,而且也符合面向对象的理念,是一种父子一来继承的关系  依赖的导入只有在各自的子工程中才会导入。--><dependencyManagement>  <dependencies>    <!--mysql驱动-->    <dependency>      <groupId>mysql</groupId>      <artifactId>mysql-connector-java</artifactId>      <version>8.0.33</version>    </dependency>    <!--持久层mybatis-->    <dependency>      <groupId>com.baomidou</groupId>      <artifactId>mybatis-plus-boot-starter</artifactId>      <version>3.5.0</version>    </dependency>    <dependency>      <groupId>com.github.pagehelper</groupId>      <artifactId>pagehelper-spring-boot-starter</artifactId>      <version>1.4.1</version>    </dependency>    <!--jackson-->    <dependency>      <groupId>com.fasterxml.jackson.core</groupId>      <artifactId>jackson-core</artifactId>      <version>2.14.2</version>    </dependency>    <dependency>      <groupId>com.fasterxml.jackson.core</groupId>      <artifactId>jackson-annotations</artifactId>      <version>2.14.2</version>    </dependency>    <dependency>      <groupId>com.fasterxml.jackson.core</groupId>      <artifactId>jackson-databind</artifactId>      <version>2.14.2</version>    </dependency>    <!--apache工具类-->    <dependency>      <groupId>commons-codec</groupId>      <artifactId>commons-codec</artifactId>      <version>1.15</version>    </dependency>    <dependency>      <groupId>org.apache.commons</groupId>      <artifactId>commons-lang3</artifactId>      <version>3.12.0</version>    </dependency>    <dependency>      <groupId>commons-fileupload</groupId>      <artifactId>commons-fileupload</artifactId>      <version>1.4</version>    </dependency>    <dependency>      <groupId>commons-io</groupId>      <artifactId>commons-io</artifactId>      <version>2.11.0</version>    </dependency>    <dependency>      <groupId>org.apache.httpcomponents</groupId>      <artifactId>httpclient</artifactId>      <version>4.5.13</version>    </dependency>    <!--google工具类-->    <dependency>      <groupId>com.google.guava</groupId>      <artifactId>guava</artifactId>      <version>28.2-jre</version>    </dependency>  </dependencies></dependencyManagement>使用zaddzset10value120value230value3:设置member和对应的分数zrangezset0-1:查看所有zset中的内容zrangezset0-1withscores:带有分数zrankzsetvalue:获得对应的下标zscorezsetvalue:获得对应的分数zcardzset:统计个数zcountzset分数1分数2:统计个数zrangebyscorezset分数1分数2:查询分数之间的member(包含分数1分数2)zrangebyscorezset(分数1(分数2:查询分数之间的member(不包含分数1和分数2)zrangebyscorezset分数1分数2limitstartend:查询分数之间的member(包含分数1分数2),获得的结果集再次根据下标区间做查询zremzsetvalue:删除member在common中引入的坐标依赖<dependency>  <groupId>org.apache.commons</groupId>  <artifactId>commons-lang3</artifactId></dependency><dependency>  <groupId>com.fasterxml.jackson.core</groupId>  <artifactId>jackson-core</artifactId></dependency><dependency>  <groupId>com.fasterxml.jackson.core</groupId>  <artifactId>jackson-annotations</artifactId></dependency><dependency>  <groupId>com.fasterxml.jackson.core</groupId>  <artifactId>jackson-databind</artifactId></dependency><dependency>  <groupId>com.fasterxml.jackson.datatype</groupId>  <artifactId>jackson-datatype-jsr310</artifactId></dependency>迭代查询代码,一级缓存与二级缓存结合:@GetMapping("query")publicObjectquery(Stringid){  StringarticleKey="article:"+id;  StringarticleKeyRedis="REDIS_ARTICLE:"+id;  Articlearticle=cache.get(articleKey,s->{    System.out.println("文章id为"+id+"的没有查询到,则从Redis中查询后返回...");    ArticlearticleReal=null;    StringarticleJsonStr=redis.get(articleKeyRedis);    //判断从redis中查询到的文章数据是否为空    if(StringUtils.isBlank(articleJsonStr)){      System.out.println("Redis中不存在该文章,将从数据库中查询...");      //如果为空,则进入本条件,则从数据库中查询数据      articleReal=articleService.queryArticleDetail(id);      //手动把文章数据设置到redis中,后续再次查询则有值      StringarticleJson=JsonUtils.objectToJson(articleReal);      redis.set(articleKeyRedis,articleJson);    }else{      System.out.println("Redis中存在该文章,将直接返回...");      //如果不为空,则直接转换json类型article再返回即可      articleReal=JsonUtils.jsonToPojo(articleJsonStr,Article.class);    }    returnarticleReal;  });  returnarticle;}本文到此结束,感谢大家的阅读!
  • 所需E币: 0
    时间: 2023-6-7 09:14
    大小: 2.81KB
    学完《C++微服务架构及安全云盘项目实训》课,您将学到:从实践中理解软件工程,学习需求分析、架构设计、详细设计文档的编写,学习编程规范,了解多人协作开发策略,理解并引用软件的版本管理,熟悉git工具和软件发布管理流程,bug管理提交问题。课程大纲:第一阶段环境准备开发工具安装、系统和虚拟机安装、sdk库编译安装代码规范说明(参考google代码规范)版本管理讲解,使用git第二阶段原型开发不做设计、不用框架、直接基于qt+libevent开发出云盘的后端和前端上传下载和目录功能教会同学碰到需求如何思考开发出原型第三阶段0.1版本微服务框架编写需求分析、架构设计、详细设计文档完成版本管理策略完成主体框架开发,基于libevent第四阶段1.0版本微服务框架完成微服务架构完成基于protobuf的通信RPC模块完成公共服务(认证、日志、监控)第五阶段1.1版本微服务框架添加加密和压缩通信,完成后端服务注册和管理,完成服务的自动启动和停止管理优化负载均衡,完成运维管理第六阶段基于框架安全云盘的业务功能支持高并发的文件上传下载,支持秒传和文件完整性校验,支持文件加密存储和传输,支持图片视频生成缩略图,支持视频生成gif预览动画,支持文件共享和分发第七阶段学员独立微服务开发辅导安全云盘扩展功能,可以是前端或者是后端服务直播评审学员代码
  • 所需E币: 3
    时间: 2023-6-1 16:44
    大小: 92.04MB
    上传者: 青大椒
    介绍计算机操作系统级架构的书籍
  • 所需E币: 0
    时间: 2023-5-30 15:46
    大小: 512B
    上传者: 蝴蝶结欧恩
    分享课程——C++微服务架构及安全云盘项目实训,包含课程配套资料下载。本课程从实践中理解软件工程,学习需求分析、架构设计、详细设计文档的编写,学习编程规范,了解多人协作开发策略,理解并引用软件的版本管理,熟悉git工具和软件发布管理流程,bug管理提交问题。
  • 所需E币: 2
    时间: 2023-5-12 16:20
    大小: 69.2MB
    云计算:概念、技术与架构-(计算机科学丛书)-[美]ThomasErl-[英]ZaighamMahmood-[巴西]RicardoPuttini
  • 所需E币: 1
    时间: 2023-5-12 11:55
    大小: 3.24MB
    Serverless从入门到进阶:架构、原理与实践-(云计算与虚拟化技术丛书)-方坤丁-孙远高
  • 所需E币: 1
    时间: 2023-5-9 15:07
    大小: 22.75MB
    大数据技术体系详解:原理、架构与实践-(大数据技术丛书)-董西成(mobi格式,附阅读器安装程序)
  • 所需E币: 1
    时间: 2023-5-6 15:56
    大小: 181.78MB
    分布式服务架构:原理、设计与实战-李艳鹏-杨彪
  • 所需E币: 0
    时间: 2023-4-29 11:02
    大小: 140.14MB
    上传者: eisbergeisberg
    大话计算机:计算机系统底层架构原理极限剖析 卷1
  • 所需E币: 5
    时间: 2023-4-27 10:30
    大小: 21.24MB
    鲲鹏架构入门与实战-张磊(epub格式,附阅读器安装程序)
  • 所需E币: 1
    时间: 2023-4-18 11:50
    大小: 7.22MB
    企业大数据系统构建实战:技术、架构、实施与应用-(大数据技术丛书)-吕兆星
  • 所需E币: 1
    时间: 2023-4-24 15:28
    大小: 161.24MB
    大话计算机:计算机系统底层架构原理极限剖析
  • 所需E币: 0
    时间: 2023-4-23 08:11
    大小: 2.21MB
    上传者: EPTmachine
    03AUTOSAR分层架构_625841
  • 所需E币: 0
    时间: 2023-4-23 08:12
    大小: 2.29MB
    上传者: EPTmachine
    13ECU软件的AUTOSAR分层架构_625851
  • 所需E币: 0
    时间: 2023-4-23 08:12
    大小: 1.79MB
    上传者: EPTmachine
    10基于AUTOSAR架构的控制系统开发流程_625848
  • 所需E币: 1
    时间: 2023-4-10 11:38
    大小: 146.62MB
    游戏引擎架构-[美]JasonGregory
  • 所需E币: 1
    时间: 2023-3-29 21:27
    大小: 2.56MB
    上传者: 指的是在下
    基于配置信息动态压缩的可重构架构优化.pdf
  • 所需E币: 1
    时间: 2023-3-29 20:58
    大小: 555.01KB
    上传者: 指的是在下
    多种中值滤波算法在可重构架构上的映射实现_通信论文