首页 文章 精选 留言 我的

精选列表

搜索[Hypercore引擎]，共10000篇文章
优秀的个人博客,低调大师

Milvus 向量搜索引擎 0.6.0 新功能介绍

Gitee:https://gitee.com/milvus-io/milvus 发布时间：2019-12-07 版本兼容 Milvus 版本 pymilvus 版本 Java SDK 版本 0.6.0 0.2.6 0.4.0 ✨新增功能 仅需 CPU 的 Milvus 在之前的版本，我们只提供了 GPU 版本的 Milvus。为了降低用户使用门槛，从 v0.6.0 开始，Milvus 提供仅需 CPU 和支持 GPU 两个版本的 Docker 镜像。CPU 版适合百万级数据的查询，而 GPU 版在超大数据集搜索情况下性能优势更明显。 您也可以源码编译，但考虑到编译环境复杂多变，有可能会增加编译困难，我们在新版本提供了 Ubuntu 18.04 的 Docker 镜像，便于大家直接在 Docker 容器中编译 Milvus。 更多信息，请参阅 PR#192: https://github.com/milvus-io/milvus/pull/192 Milvus 安装步骤: https://www.milvus.io/docs/zh-CN/userguide/install_milvus/ CPU 版镜像下载：milvusdb/milvus:cpu-latest GPU 版镜像下载：milvusdb/milvus:latest 分区表 随着单张表的数据量不断增长，查询性能也会不断下降。单张表的数据变得很臃肿的时候，就要考虑将这张表拆分。v0.6.0 新增了分区表功能以确保增量数据的高性能查询。Milvus 的表基于标签分区，通过定义partition_tag，您可以指定某张分区表，每张分区表的索引继承自母表。Python，Java 和 C++ SDK 中也分别增加了表分区功能的相关接口，目前支持创建/删除分区表，向量插入指定分区表，查看指定分区表，以及指定分区表的查询。 更多信息，请参阅 PR#245:https://github.com/milvus-io/milvus/pull/245 实验功能 v0.6.0还推出了一些实验功能，代表了 Milvus 未来版本可能发展的方向。这些实验功能仍在持续开发和更新中，可能包含已知问题和未发现的错误。现阶段这些功能主要用于测试和用户反馈收集，欢迎大家积极试用。 Mishards Milvus 旨在帮助用户实现海量非结构化数据的近似检索和分析。单个 Milvus 实例可处理十亿级数据规模，而对于百亿或者千亿级数据，则需要一个 Milvus 集群实例。v0.6.0 推出的 Mishards 正是 Milvus 集群分片处理的中间件，主要负责将上游请求拆分，并路由到内部各细分子服务，最后将子服务结果汇总，返回给上游。Mishards 内部处理请求转发、读写分离、水平扩展、动态扩容，为用户提供内存和算力可以无限扩容的 Milvus 集群实例。 更多信息，请参阅PR#232: https://github.com/milvus-io/milvus/pull/232 新的索引类型 支持新的索引类型如SPTAG-KDT，SPTAG-BKT,RNSG和IVFPQ。Milvus 集成了微软的 SPTAG 算法库，包含两种索引类型。RNSG是 Milvus 在 NSG 基础上自研的基于图的索引算法，它可以 a) 降低图的平均出度；b) 缩短搜索路径；c) 缩减索引大小；d) 降低索引复杂度。IVF_PQ是在倒排索引的基础上进一步利用笛卡儿积（PQ）对每一个倒排文件中的向量进行编码的索引技术。这样的方法称之为非对称距离计算。向量大小可以缩减至原来大小的1/8甚至1/16。该索引方式虽然会损失精度，但内存占用会进一步下降，适用于低内存环境下的大规模向量搜索。 目前看来，这几种新的索引类型的搜索性能表现并不令人满意，具体原因还有待进一步发掘，也欢迎感兴趣的小伙伴一起加入研究讨论。 更多信息，请参阅 SPTAG-PR#438:https://github.com/milvus-io/milvus/pull/438 RNSG-PR#554:https://github.com/milvus-io/milvus/pull/554 IVFPQ-PR#324:https://github.com/milvus-io/milvus/pull/324 SPTAG 索引介绍:https://github.com/Microsoft/SPTAG NSG 索引论文:https://arxiv.org/abs/1707.00143 Milvus 性能测试报告 Milvus 支持多种类型的索引，各个索引的查询性能会随着数据集和调参的变化而改变。新版本提供了针对IVFFLAT,IVFSQ8和IVFSQ8H的性能测试报告。随着 Milvus 支持的索引类型不断增加，测试报告也会持续更新。 具体性能测试报告，请参阅索引性能测试:https://github.com/milvus-io/milvus/tree/master/docs ✨主要改进 Milvus 优化过的 FAISS 在原有 FAISS 的基础上， Milvus 做了一些深层代码的优化以获得更优的查询性能和支持更多类型的索引类型，比如IVFSQ8H。现在，我们将这部分针对 FAISS 进行优化的代码开源了。 更多信息，请参阅PR#585: https://github.com/milvus-io/milvus/pull/585 多张 GPU 创建索引 支持使用多张 GPU 来创建索引以减少创建索引和整体查询的时间。在使用支持 GPU 的 Milvus 时，您可以通过对 Milvus 配置文件中的参数build_index_resources来指定多张 GPU 卡用于索引创建。 更多信息，请参阅 PR#414:https://github.com/milvus-io/milvus/pull/414 ✨Bug 修复 进一步解决了随查询次数增加，内存占用持续增加的问题。 更多信息，请参阅 PR#335: https://github.com/milvus-io/milvus/pull/335 如果还想了解 v0.6.0 更具体的更新改动，请参阅Milvus CHANGELOG:https://github.com/milvus-io/milvus/blob/master/CHANGELOG.md 欢迎加入Milvus社区 主页：milvus.io GitHub：github.com/milvus-io/milvus 知乎：zhuanlan.zhihu.com/milvus Slack：milvusio.slack.com Twitter：twitter.com/milvusio Facebook：www.facebook.com/io.milvus.5
2019-12-20
优秀的个人博客,低调大师

OpenLayers 6.0.0 发布，高性能开源地图引擎

OpenLayers 是一个高性能、功能丰富的库，用于在 Web 上创建交互式地图。它可以显示从任何来源加载的地图图块、矢量数据和标记。6.0.0版本内容如下： 能够使用不同的渲染器类型组成层：以前，地图使用单一的渲染策略，地图中的所有层都必须实现该策略。现在可以使用不同的渲染技术拥有一个具有不同层的映射 可以使用自定义渲染器创建层：可以使用另一个库(如 d3)来渲染一个层，而使用 OpenLayers 来渲染其他层 一些矢量切片(vector tile)渲染改进，具有较低的内存占用 此版本包括一些实验特性的 API 此版本包含许多向后不兼容的更改 缓存起始坐标，并向 translateEvent 添加 mapBrowserEvent 为 hasFeatureAtPixel 和 getFeaturesAtPixel 添加地理测试 该版本做了很多改进和修复，详情可见更新说明： https://github.com/openlayers/openlayers/releases/tag/v6.0.0
2019-09-28
优秀的个人博客,低调大师

解读 Kylin 3.0.0 | 更敏捷、更高效的 OLAP 引擎

在近期的 Apache Kylin Meetup 成都站上，我们邀请到 Kyligence 架构师 & Apache Kylin Committer 倪春恩对 Kylin3.0.0 版本的一些重要功能及改进从使用到原理进行了介绍： Apache Kylin 在今年 4 月 18 日发布了 3.0.0 Alpha 版本，我今天的分享也围绕Release notes内提到的三个功能，即：基于 Curator 的作业调度器，使用 Apache Livy 提交 Spark 任务，实时 OLAP。 基于 Curator 的作业调度器 首先讲一下作业调度器。Kylin 支持集群部署， Kylin 实例主要有三种模式。一种是 Job 模式（用作任务构建），一种是 Query 模式（用作 Query 查询），配置成all模式的节点既做 Query 节点又做 Job节点。之前，我们需要先设置配置项，配置 kylin.server.cluster-servers 为集群中所有节点，这样各节点便可互相通信，比如元数据的同步。 我们可以通过 Ngnix 等工具配一个对 Kylin 集群查询的多活，即便有某个节点挂掉了，也不会影响 Kylin 的查询使用。但在原有的默认模式下，是不支持任务构建的高可用的。在默认的任务调度模式下，Job 节点会在 ZooKeeper 的一个路径下生成一个临时节点作为并发锁，只有持有锁的节点才会启动任务调度器。但如果发生一些情况，这个任务节点退出了，或者是 ZooKeeper 服务异常，都会导致所有的构建任务、merge 任务无法执行，别的任务节点也没有办法把这些任务 takeover 起来。 另外，所有的 Kylin 节点都需要配置集群节点列表的配置项 kylin.server.cluster-servers，一旦需要往集群添加节点，所有的节点配置项都必须改，非常不利于集群的扩展，一旦某个节点没有配正确，就会发生很多异常情况。 接下来介绍 Curator。Curator 是一个 Apache 的孵化项目，Curator 框架提供了一套高级的 API， 简化了 ZooKeeper 的操作。它增加了很多使用 ZooKeeper 开发的特性，可以处理 ZooKeeper 集群复杂的连接管理和重试机制。Service Discovery 是 Curator 的一个模块，他提供了 Service 的注册机制，对一个新 Service的注册，Service 的状态变更事件，别的 Service 能够立即得到相应。 基于 Curator 的作业调度器的配置方法很简单，把配置项 kylin.job.scheduler.default 配置成 100 即可。启动后，所有节点都会往 ZK 里面去注册临时节点，每个临时节点写有节点 url，模式等基本信息。 在此模式下的任务调度，只会有一个被选举出来的任务节点，来执行任务调度。多节点的 Leader 选举，是基于 Curator 的 Leader 选举。它具有这样的特点： 每个实例都能公平获取领导权 获取领导权的实例在释放领导权之后，该实例还有机会再次获取领导权 每个 Job 或 All 节点会往 leader 路径下创建节点，获得领导权的任务节点会启动任务调度器。失去了领导权后，该节点会中断所有的构建任务，另一台节点会紧接着获取新的领导权，把所有的任务给恢复起来。 另外在系统页面会有一个节点监控页面，用户可以看到各节点的类型与状态。 该任务调度模式的优点有： 实现了 HA，保证构建任务的持续执行 方便进行节点扩展 配置方便，减少运维成本 便于监控 使用 Apache Livy 提交 Spark 任务 第二个 Feature 是支持使用 Apache Livy 提交 Spark 任务，Livy 是一个基于 Spark 的开源 REST 服务，它能够通过 REST 的方式将代码片段或是序列化的二进制代码提交到 Spark 集群中去执行。它提供了以下这些基本功能： 提交 Scala、Python 或是 R 代码片段到远端的 Spark 集群上执行 提交 Java、Scala、Python 所编写的 Spark 作业到远端的 Spark 集群上执行 提交批处理应用在集群中运行 对应到 Kylin，需要作如下配置： kylin.engine.livy-conf.livy-enabled=true kylin.engine.livy-conf.livy-url={url of Livy server} kylin.engine.livy-conf.livy-key.file={path for kylin job jar} kylin.engine.livy-conf.livy-arr.jars={paths for dependencies} 首先开关 kylin.engine.livy-conf.livy-enabled 需要打开，默认是关闭的。其次是配上 Livy rest server 的 url 到 kylin.engine.livy-conf.livy-url，另外需要配上任务 jar 包的路径到 kylin.engine.livy-conf.livy-key.file，最后是 kylin.engine.livy-conf.livy-arr.jars 需配置为任务依赖的 jar 包。下图为使用 Livy 服务进行 Spark 构建发送的请求日志，从中可以看到相应的参数。 默认情况下，每个 Kylin 节点都要配置自己的 Spark home，有了此功能，所有的任务节点都需要往一个 Spark Uil 去提交任务，这样就比较方便管理和监控。 实时 OLAP Kylin 在 2014 年由 eBay 开发完成，初衷是解决海量数据快速交互式分析的问题，数据源只支持 Hive。Kylin 在 v1.6 引入的准实时数据摄入，但是还是需要触发构建，至少会有数分钟的延迟。eBay 开发团队基于 Kylin 开发了 Real-time OLAP 的特性，实现了 Kylin 对 Kafka 流式数据的实时查询。eBay 内部已将此功能用于生产，并稳定运行超过一年时间。该 feature 于 2018 年下半年开源，并在 v3.0-alpha 里正式发布。 Ø 实时 OLAP 基本架构 在新的架构下，数据查询请求根据时间分区列(Timestamp Partition Column)分为两部分， 历史数据的查询请求仍将发送给 HBase Region Server，最新时间段的查询请求将发送到实时计算节点，Query Server 需要将两者的结果整合后返回给查询客户端。 与此同时，实时计算节点会不断将本地数据上传到 HDFS，在满足一定条件时会通过 Hadoop 来构建 segment，从而完成实时数据向历史数据的转化，并且实现了降低实时计算节点压力的目的。 Ø Real-time OLAP 的概念和角色 为实现 Real-time OLAP， Kylin 引入了一些新的概念。 1. Streaming Receiver Streaming Receiver 的角色是 worker，每个 receiver 是一个 Java 进程，受Coordinator 的管理，它的主要职责包含: 实时摄入数据 在内存构建 cuboid，定时将保存在内存的 cuboid 数据 flush 到磁盘，形成Fragment 文件 定时 checkpoint 和合并 Fragment 文件 接受对它所负责的 Partition 的查询请求 当 segment 变为不可变后，上传到 HDFS 或者从本地删除（依据配置） 2. Receiver Cluster Streaming Receiver 组成的集合称为 Receiver 集群。 3. Streaming Coordinator Streaming Coordinator 作为 Receiver 集群的 Master 节点，主要职责是管理 Receiver，包括将 Kafka topic 的 partition 分配/解除分配到指定的 Replica set、 暂停或者恢复消费、收集和展示各项统计指标(例如 message per second)。当 kylin.server.mode 被设置为 all 或者 stream_coordinator，这个进程就成为一个Streaming Coordinator。Coordinator 只处理元数据和集群调度，不摄入消息。 4. Coordinator Cluster 多个Coordinator 可以同时存在，组成一个 Coordinator 集群。在多个 Coordinator 中，同一时刻只存在一个 Leader，只有 Leader 才可以响应请求，其余进程作为 standby/backup。 5. Replica Set Replica Set 是一组 Streaming Receiver，它们动作一致。Replica Set 作为任务分配的最小单位，Replica Set 下的所有 Receiver 做相同的工作(即摄入相同的一组 partition)，互为 backup。当集群中存在一些 Receiver 进程无法访问，能保证每一个 Replica Set 至少存在一个健康的 Receiver，那么集群仍能正常工作并且返回合理的查询结果。在一个 Replica Set 中，将存在一个 Leader Receiver 来做额外的工作，其余的 Receiver 作为 Follower。 Ø Real-time OLAP 的整体架构 下图为 Kylin 实时 OLAP 的整体架构，数据流向方面，是从 Kafka 到 Receiver，再由 Receiver 上传到 HDFS，最后由 MapReduce 程序合并和重新加工 Segment 进入 HBase。 查询方面，查询请求由 Query Server 发出，根据查询条件中出现的时间分区列，分发请求到 Receiver 和 HBase Region Server 两端。 Topic Partition 的分配和 Rebalance、Segment 状态管理和作业提交由 Coordinator 负 责。 另外在实时构建中，Kylin 使用 ZooKeeper 进行元数据的存储。 Q & A 提问：Kylin 实时 OLAP 的数据消费都是针对 Kafka，我最近也在去做 POC，就是针对 Kylin v3.0。我发现了在消费 Kafka 数据的时候，3 个 Server 里，有的 Server 摄取了全量数据，有的不是，这个我不太清楚具体是什么一个情况。 回答：你可以点击某一个 Receiver，可以看到这个 Receiver 对这个 Cube 的消费统计数据。 提问：还有消费延迟，这个怎么去解决这个问题呢? 回答：数据消费延迟在我们的测试环境也有，目前来讲处理的方法是通过 Server 的扩容。 提问：刚才也听您说了很多 Kylin 实时的一些原理，同 Spark Streaming 和 Flink 相比，有什么优点？ 回答：Kylin 和他们不是在一个层面的，Spark Streaming 和 Flink 是更加通用的计算框架，而 Kylin 是一个 OLAP 的应用，通过预计算，对于一个查询，它的目标是直接去拿到一个结果。 提问：我想问的就是刚才那个保留状态，他能保证比如说数据没处理到的，可以实现端到端一次性不丢失吗？就是在消费过来的数据时服务挂掉了，这时候进来的那部分数据会丢失吗，就是从 Kafka 数据去消费的时候？ 回答：这个还是得看时间窗口的配置，Kylin Realtime 会按配置接受一定时间延迟的数据进来。但如果过了这个配置的最大时间，是没办法被构建的，因为对应的 Segment 已经变成一个本地的只可读不可写的状态。 了解更多大数据资讯，点击进入Kyligence官网 --------------------------------------------------------------------------------------------- 2019 年 9 月 7 日 Apache Kylin × Apache RocketMQ Meetup 深圳站正在火热报名！邀请到腾讯、阿里 、平安云以及 Kyligence的技术专家为大家呈现精彩应用案例与实践：https://www.huodongxing.com/event/3506680147611
2019-06-16
优秀的个人博客,低调大师

Solr搜索引擎 — SolrCloud介绍和环境准备

搞定了一切的一切之后下一步就是正式使用了，但是之前介绍的都是在单台服务器上进行的部署，如果在生产环境出现了单台故障怎么办呢？提供稳定性和性能的最直观的方式就是集群，solr官方提供了cloud的集群方式 附上: 喵了个咪的博客：http://w-blog.cn Solr官网：http://lucene.apache.org/solr/ PS：8.0.0版本已经发布，本文使用此时较为稳定的7.7.1版本 一，SolrCloud介绍 SolrCloud是基于Solr和Zookeeper的分布式搜索方案。它的主要思想是使用Zookeeper作为SolrCloud集群的配置信息中心，统一管理solrcloud的配置，比如solrconfig.xml和schema.xml。 SolrCloud(solr集群)是Solr提供的分布式搜索方案，一下场景能够比较好的使用SolrCloud 当你需要大规模，容错，分布式索引和检索能力时使用SolrCloud。 当索引量很大，搜索请求并发很高时，同样需要使用SolrCloud来满足这些需求。 不过当一个系统的索引数据量少的时候是没有必要使用SolrCloud的。 Solrcloud特点功能： 集中式的配置信息 自动容错 近实时搜索 查询时自动负载均衡 Solrcloud的结构： solrcloud为了降低单机的处理压力，需要由多台服务器共同来完成索引和搜索任务。实现的思路是将索引数据进行Shard分片，每个分片由多台服务器共同完成，当一个索引或搜索请求过来时会分别从不同的Shard的服务器中操作索引。solrcloud是基于solr和zookeeper部署，zookeeper是一个集群管理软件，solrcloud需要由多台solr服务器组成，然后由zookeeper来进行协调管理。 物理结构： 三个Solr实例（ 每个实例包括两个Core），组成一个SolrCloud。 逻辑结构： 索引集合包括两个Shard（shard1和shard2），shard1和shard2分别由三个Core组成，其中一个Leader两个Replication，Leader是由zookeeper选举产生，zookeeper控制每个shard上三个Core的索引数据一致，解决高可用问题。用户发起索引请求分别从shard1和shard2上获取，解决高并发问题。 core： 每个Core是Solr中一个独立运行单位，提供 索引和搜索服务。一个shard需要由一个Core或多个Core组成。由于collection由多个shard组成所以collection一般由多个core组成。 Master&Slave： Master是master-slave构中的主结点（通常说主服务器），Slave是master-slave结构中的从结点（通常说从服务器或备服务器）。同一个Shard下master和slave存储的数据是一致的，这是为了达到高可用目的 二、环境准备 准备三台centos 7服务器 , 并且对主机名进行改写 hostname solr-1 hostname solr-2 hostname solr-3 修改三台机器hosts文件通过hostname可以互相访问,使用ping命令验证可以互相通讯 > vim /etc/hosts 172.16.2.75 solr-1 172.16.2.74 solr-2 172.16.2.72 solr-3 安装JAVA,可以自行安装或oneinstack一键命令安装,这里安装了java和tomcat > wget -c http://mirrors.linuxeye.com/oneinstack-full.tar.gz && tar xzf oneinstack-full.tar.gz && ./oneinstack/install.sh --tomcat_option 2 --jdk_option 2 --reboot 三、Zookeeper安装 > cd /app/install/ > wget http://mirrors.hust.edu.cn/apache/zookeeper/zookeeper-3.4.13/zookeeper-3.4.13.tar.gz > tar -zxvf zookeeper-3.4.13.tar.gz > mv zookeeper-3.4.13 /usr/local/ 修改配置文件 > cd /usr/local/zookeeper-3.4.13/conf/ > cp zoo_sample.cfg zoo.cfg > vim zoo.cfg tickTime=2000 dataDir=/usr/local/zookeeper-3.4.13/data clientPort=2181 initLimit=10 syncLimit=5 server.1=solr-1:2888:3888 server.2=solr-2:2888:3888 server.3=solr-3:2888:3888 所有节点修改环境变量 > vim /etc/profile # zookeeper export ZOOKEEPER_HOME=/usr/local/zookeeper-3.4.13 export PATH=$ZOOKEEPER_HOME/bin:$PATH > source /etc/profile 将zookeeper目录复制到其他节点上 > scp -r /usr/local/zookeeper-3.4.13/ root@solr-2:/usr/local/zookeeper-3.4.13 > scp -r /usr/local/zookeeper-3.4.13/ root@solr-3:/usr/local/zookeeper-3.4.13 添加myid文件(每节点都需要) > cd /usr/local/zookeeper-3.4.13 > mkdir data > echo "1" > data/myid 注意，每个节点myid文件要不一致 启动并测试 # 在三台机器上分别执行 > zkServer.sh start # 查看状态 [root@solr-1 zookeeper-3.4.13]# zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/zookeeper-3.4.13/bin/../conf/zoo.cfg Mode: follower [root@solr-2 zookeeper-3.4.13]# zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/zookeeper-3.4.13/bin/../conf/zoo.cfg Mode: leader [root@solr-3 zookeeper-3.4.13]# zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/zookeeper-3.4.13/bin/../conf/zoo.cfg Mode: follower
2019-05-20
优秀的个人博客,低调大师

基于Unity3d 引擎的Android游戏优化

更新不透明贴图的压缩格式为ETC 4bit，因为android市场的手机中的GPU有多种，每家的GPU支持不同的压缩格式，但他们都兼容ETC格式， 对于透明贴图，我们只能选择RGBA 16bit 或者RGBA 32bit。 减少FPS，在ProjectSetting-> Quality中的VSync Count 参数会影响你的FPS，EveryVBlank相当于FPS=60，EverySecondVBlank = 30；这两种情况都不符合游戏的FPS的话，我们需要手动调整FPS，首先关闭垂直同步这个功能，然后在代码的Awake方法里手动设置FPS（Application.targetFrameRate = 45;） 降低FPS的好处：1）省电，减少手机发热的情况；2）能都稳定游戏FPS，减少出现卡顿的情况。 当我们设置了FPS后，再调整下Fixed timestep这个参数，这个参数在ProjectSetting->Time中，目的是减少物理计算的次数，来提高游戏性能。 尽量少使用Update LateUpdate FixedUpdate，这样也可以提升性能和节省电量。多使用事件（不是SendMessage，使用自己写的，或者C#中的事件委托）。 待机时，调整游戏的FPS为1，节省电量。 遇到麻烦时要调用“垃圾回收器”（Garbage Collector，无用单元收集程序，以下简称GC）由于具有C/C++游戏编程背景，我们并不习惯无用单元收集程序的特定行为。确保自动清理你不用的内存，这种做法在刚开始时很好，但很快你就公发现自己的 分析器经常显示CPU负荷过大，原因是垃圾回收器正在收集垃圾内存。这对移动设备来说尤其是个大问题。要跟进内存分配，并尽量避免它们成为优先数 更多unity2018的功能介绍请到paws3d学习中心查找。
2019-02-27

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册