事务性Topologies是包含在Storm0.7.0版本中的新特性,它激活消息语义来确保你以一种安全的方式重放元组并且它们只会被处理一次。没有事务性topologies的支持,你不可能以一种完全精确、可扩展和容错的方式计数。
事务性Topologies是建立标准Storm spout和bolts之上的一个抽象。
设计
在事务性topology中,Storm使用并行和顺序元组处理的混合模式。Spout产生的批量的元组被bolts并行的处理。这些bolts中的一部分被认为是提交者,它们以某种严格排序的方式提交处理过的批量元组。这意味着如果你有两个批量,每个批量包含五个元组,两边的元组会被bolts以并行的方式处理,但是提交者bolts直到第一个元组被提交成功后才会提交第二个元组。
当处理事务性Topology时,可以从源重放批量的元组,甚至有时候是多次重放是非常重要的。所以确保你的数据源--你的spout将要连接的那个--具备这个能力。
这可以被描述成两个不同的步骤,或者阶段:
处理阶段
完全并行的阶段,许多批量被同时执行。
提交阶段
严格排序的阶段,第二个批量直到第一个批量被提交成功后才提交。
把这两个阶段称为Storm事务。
storm使用zookeeper来保存事务元数据。缺省的情况下就使用为topology服务的那个zookeeper来保存元数据。你可以通过覆盖配置键transactional.zookeeper.servers 和 transactional.zookeeper.port.来更改。
事务实战
为看清事务怎样工作,你将建立一个Twitter分析工具。你会读取存储在Redis中的tweets,通过一系列bolts处理他们,然后存储--在另一个Redis数据库中--所有标签和它们在tweets中的频率的列表,所有用户和他们出现在tweets中的总计的列表和一个用户及他们标签和频率的列表。
正如你看到的, TweetsTransactionalSpout 会连接你的tweet数据库并向拓扑分发批次。 UserSplitterBolt 和 HashTagSplitterBolt 两个 bolt ,从 spout 接收元组。 UserSplitterBolt 解析tweets并查找用户——以@开头的单词——然后把这些单词分发到名为 users 的自定义数据流组。 HashtagSplitterBolt 从tweet查找 # 开头的单词,并把它们分发到名为 hashtags 的自定义数据流组。第三个 bolt , UserHashtagJoinBolt ,接收前面提到的两个数据流组,并计算具名用户的一条tweet内的话题数量。为了计数并分发计算结果,这是个 BaseBatchBolt (稍后有更多介绍)。
最后一个bolt—— RedisCommitterBolt ——接收以上三个 bolt 的数据流组。它为每样东西计数,并在对一个批次完成处理时,把所有结果保存到redis。这是一种特殊的 bolt ,叫做提交者,在本章后面做更多讲解。
用 TransactionalTopologyBuilder 构建拓扑,代码如下:
TransactionalTopologyBuilder builder= new TransactionalTopologyBuilder("test", "spout", new TweetsTransactionalSpout()); builder.setBolt("users-splitter", new UserSplitterBolt(), 4).shuffleGrouping("spout"); buildeer.setBolt("hashtag-splitter", new HashtagSplitterBolt(), 4).shuffleGrouping("spout"); builder.setBolt("users-hashtag-manager", new UserHashtagJoinBolt(), r) .fieldsGrouping("users-splitter", "users", new Fields("tweet_id")) .fieldsGrouping("hashtag-splitter", "hashtags", new Fields("tweet_id")); builder.setBolt("redis-commiter", new RedisCommiterBolt()) .globalGrouping("users-splitter", "users") .globalGrouping("hashtag-splitter", "hashtags") .globalGrouping("user-hashtag-merger");
接下来就看看如何在一个事务性拓扑中实现 spout 。
Spout
一个事务性拓扑的 spout 与标准 spout 完全不同。
public class TweetsTransactionalSpout extends BaseTransactionalSpout<TransactionMetadata>{
正如你在这个类定义中看到的,TweetsTransactionalSpout继承了带范型的 BaseTransactionalSpout 。指定的范型类型的对象是事务元数据集合。它将在后面的代码中用于从数据源分发批次。
在这个例子中, TransactionMetadata 定义如下:
public class TransactionMetadata implements Serializable { private static final long serialVersionUID = 1L; long from; int quantity; public TransactionMetadata(long from, int quantity) { this.from = from; this.quantity = quantity; } }
该类的对象维护着两个属性 from 和 quantity ,它们用来生成批次。
spout 的最后需要实现下面的三个方法:
@Override public ITransactionalSpout.Coordinator<TransactionMetadata> getCoordinator( Map conf, TopologyContext context) { return new TweetsTransactionalSpoutCoordinator(); } @Override public backtype.storm.transactional.ITransactionalSpout.Emitter<TransactionMetadata> getEmitter(Map conf, TopologyContext contest) { return new TweetsTransactionalSpoutEmitter(); } @Override public void declareOutputFields(OuputFieldsDeclarer declarer) { declarer.declare(new Fields("txid", "tweet_id", "tweet")); }
getCoordinator 方法,告诉Storm用来协调生成批次的类。 getEmitter ,负责读取批次并把它们分发到拓扑中的数据流组。最后,就像之前做过的,需要声明要分发的域。
RQ类
为了让例子简单点,我们决定用一个类封装所有对Redis的操作。
public class RQ { public static final String NEXT_READ = "NEXT_READ"; public static final String NEXT_WRITE = "NEXT_WRITE"; Jedis jedis; public RQ() { jedis = new Jedis("localhost"); } public long getavailableToRead(long current) { return getNextWrite() - current; } public long getNextRead() { String sNextRead = jedis.get(NEXT_READ); if(sNextRead == null) { return 1; } return Long.valueOf(sNextRead); } public long getNextWrite() { return Long.valueOf(jedis.get(NEXT_WRITE)); } public void close() { jedis.disconnect(); } public void setNextRead(long nextRead) { jedis.set(NEXT_READ, ""+nextRead); } public List<String> getMessages(long from, int quantity) { String[] keys = new String[quantity]; for (int i = 0; i < quantity; i++) { keys[i] = ""+(i+from); } return jedis.mget(keys); } }
仔细阅读每个方法,确保自己理解了它们的用处。
协调者Coordinator
下面是本例的协调者实现。
public static class TweetsTransactionalSpoutCoordinator implements ITransactionalSpout.Coordinator<TransactionMetadata> { TransactionMetadata lastTransactionMetadata; RQ rq = new RQ(); long nextRead = 0; public TweetsTransactionalSpoutCoordinator() { nextRead = rq.getNextRead(); } @Override public TransactionMetadata initializeTransaction(BigInteger txid, TransactionMetadata prevMetadata) { long quantity = rq.getAvailableToRead(nextRead); quantity = quantity > MAX_TRANSACTION_SIZE ? MAX_TRANSACTION_SIZE : quantity; TransactionMetadata ret = new TransactionMetadata(nextRead, (int)quantity); nextRead += quantity; return ret; } @Override public boolean isReady() { return rq.getAvailableToRead(nextRead) > 0; } @Override public void close() { rq.close(); } }
值得一提的是, 在整个拓扑中只会有一个提交者实例 。创建提交者实例时,它会从redis读取一个从1开始的序列号,这个序列号标识要读取的tweet下一条。
第一个方法是 isReady 。在 initializeTransaction 之前调用它确认数据源已就绪并可读取。此方法应当相应的返回 true 或 false 。在此例中,读取tweets数量并与已读数量比较。它们之间的不同就在于可读tweets数。如果它大于0,就意味着还有tweets未读。
最后,执行 initializeTransaction 。正如你看到的,它接收 txid 和 prevMetadata 作为参数。第一个参数是Storm生成的事务ID,作为批次的惟一性标识。 prevMetadata 是协调器生成的前一个事务元数据对象。
在这个例子中,首先确认有多少tweets可读。只要确认了这一点,就创建一个TransactionMetadata对象,标识读取的第一个tweet(译者注:对象属性 from ),以及读取的tweets数量(译者注:对象属性 quantity )。
元数据对象一经返回,Storm把它跟 txid 一起保存在zookeeper。这样就确保了一旦发生故障,Storm可以利用分发器(译者注: Emitter ,见下文)重新发送批次。
Emitter
创建事务性 spout 的最后一步是实现分发器(Emitter)。实现如下:
public static class TweetsTransactionalSpoutEmitter implements ITransactionalSpout.Emitter<TransactionMetadata> { RQ rq = new RQ(); public TweetsTransactionalSpoutEmitter() {} @Override public void emitBatch(TransactionAttempt tx, TransactionMetadata coordinatorMeta, BatchOutputCollector collector) { rq.setNextRead(coordinatorMeta.from+coordinatorMeta.quantity); List<String> messages = rq.getMessages(coordinatorMeta.from,coordinatorMeta.quantity); long tweetId = coordinatorMeta.from; for (String message : messages) { collector.emit(new Values(tx, ""+tweetId, message)); tweetId++; } } @Override public void cleanupBefore(BigInteger txid) {} @Override public void close() { rq.close(); } }
分发器从数据源读取数据并从数据流组发送数据。分发器应当问题能够为相同的事务id和事务元数据发送相同的批次。这样,如果在处理批次的过程中发生了故 障,Storm就能够利用分发器重复相同的事务id和事务元数据,并确保批次已经重复过了。Storm会在 TransactionAttempt 对象里为尝试次数增加计数(译者注: attempt id )。这样就能知道批次已经重复过了。
在这里 emitBatch 是个重要方法。在这个方法中,使用传入的元数据对象从redis得到tweets,同时增加redis维持的已读tweets数。当然它还会把读到的tweets分发到拓扑。
Bolts
首先看一下这个拓扑中的标准 bolt :
public class UserSplitterBolt implements IBasicBolt{ private static final long serialVersionUID = 1L; @Override public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declareStream("users", new Fields("txid","tweet_id","user")); } @Override public Map<String, Object> getComponentConfiguration() { return null; } @Override public void prepare(Map stormConf, TopologyContext context) {} @Override public void execute(Tuple input, BasicOutputCollector collector) { String tweet = input.getStringByField("tweet"); String tweetId = input.getStringByField("tweet_id"); StringTokenizer strTok = new StringTokenizer(tweet, " "); HashSet<String> users = new HashSet<String>(); while(strTok.hasMoreTokens()) { String user = strTok.nextToken(); //确保这是个真实的用户,并且在这个tweet中没有重复 if(user.startsWith("@") && !users.contains(user)) { collector.emit("users", new Values(tx, tweetId, user)); users.add(user); } } } @Override public void cleanup(){} }
正如本章前面提到的, UserSplitterBolt 接收元组,解析tweet文本,分发@开头的单词————tweeter用户。 HashtagSplitterBolt 的实现也非常相似。
public class HashtagSplitterBolt implements IBasicBolt{ private static final long serialVersionUID = 1L; @Override public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declareStream("hashtags", new Fields("txid","tweet_id","hashtag")); } @Override public Map<String, Object> getComponentConfiguration() { return null; } @Override public void prepare(Map stormConf, TopologyContext context) {} @Oerride public void execute(Tuple input, BasicOutputCollector collector) { String tweet = input.getStringByField("tweet"); String tweetId = input.getStringByField("tweet_id"); StringTokenizer strTok = new StringTokenizer(tweet, " "); TransactionAttempt tx = (TransactionAttempt)input.getValueByField("txid"); HashSet<String> words = new HashSet<String>(); while(strTok.hasMoreTokens()) { String word = strTok.nextToken(); if(word.startsWith("#") && !words.contains(word)){ collector.emit("hashtags", new Values(tx, tweetId, word)); words.add(word); } } } @Override public void cleanup(){} }
现在看看 UserHashTagJoinBolt 的实现。首先要注意的是它是一个 BaseBatchBolt 。这意味着, execute 方法会操作接收到的元组,但是不会分发新的元组。批次完成时,Storm会调用 finishBatch 方法。
public void execute(Tuple tuple) { String source = tuple.getSourceStreamId(); String tweetId = tuple.getStringByField("tweet_id"); if("hashtags".equals(source)) { String hashtag = tuple.getStringByField("hashtag"); add(tweetHashtags, tweetId, hashtag); } else if("users".equals(source)) { String user = tuple.getStringByField("user"); add(userTweets, user, tweetId); } }
既然要结合tweet中提到的用户为出现的所有话题计数,就需要加入前面的 bolts 创建的两个数据流组。这件事要以批次为单位进程,在批次处理完成时,调用 finishBatch 方法。
@Override public void finishBatch() { for(String user:userTweets.keySet()){ Set<String> tweets = getUserTweets(user); HashMap<String, Integer> hashtagsCounter = new HashMap<String, Integer>(); for(String tweet:tweets){ Set<String> hashtags=getTweetHashtags(tweet); if(hashtags!=null){ for(String hashtag:hashtags){ Integer count=hashtagsCounter.get(hashtag); if(count==null){count=0;} count++; hashtagsCounter.put(hashtag,count); } } } for(String hashtag:hashtagsCounter.keySet()){ int count=hashtagsCounter.get(hashtag); collector.emit(new Values(id,user,hashtag,count)); } } }
这个方法计算每对用户-话题出现的次数,并为之生成和分发元组。
你可以在GitHub上找到并下载完整代码。(译者注:https://github.com/storm-book/examples-ch08-transactional-topologies这个仓库里没有代码,谁知道哪里有代码麻烦说一声。)
提交者 bolts
我们已经学习了,批次通过协调器和分发器怎样在拓扑中传递。在拓扑中,这些批次中的元组以并行的,没有特定次序的方式处理。
协调者bolts 是一类特殊的批处理 bolts ,它们实现了 IComh mitter 或者通过 TransactionalTopologyBuilder 调用 setCommiterBolt 设置了提交者 bolt 。它们与其它的批处理 bolts 最大的不同在于,提交者 bolts 的 finishBatch 方法在提交就绪时执行。这一点发生在之前所有事务都已成功提交之后。另外, finishBatch 方法是顺序执行的。因此如果同时有事务ID1和事务ID2两个事务同时执行,只有在ID1没有任何差错的执行了 finishBatch 方法之后,ID2才会执行该方法。
下面是这个类的实现
public class RedisCommiterCommiterBolt extends BaseTransactionalBolt implements ICommitter { public static final String LAST_COMMITED_TRANSACTION_FIELD = "LAST_COMMIT"; TransactionAttempt id; BatchOutputCollector collector; Jedis jedis; @Override public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, TransactionAttempt id) { this.id = id; this.collector = collector; this.jedis = new Jedis("localhost"); } HashMap<String, Long> hashtags = new HashMap<String,Long>(); HashMap<String, Long> users = new HashMap<String, Long>(); HashMap<String, Long> usersHashtags = new HashMap<String, Long>(); private void count(HashMap<String, Long> map, String key, int count) { Long value = map.get(key); if(value == null){value = (long)0;} value += count; map.put(key,value); } @Override public void execute(Tuple tuple) { String origin = tuple. getSourceComponent(); if("sers-splitter".equals(origin)) { String user = tuple.getStringByField("user"); count(users, user, 1); } else if("hashtag-splitter".equals(origin)) { String hashtag = tuple.getStringByField("hashtag"); count(hashtags, hashtag, 1); } else if("user-hashtag-merger".quals(origin)) { String hashtag = tuple.getStringByField("hashtag"); String user = tuple.getStringByField("user"); String key = user + ":" + hashtag; Integer count = tuple.getIntegerByField("count"); count(usersHashtags, key, count); } } @Override public void finishBatch() { String lastCommitedTransaction = jedis.get(LAST_COMMITED_TRANSACTION_FIELD); String currentTransaction = ""+id.getTransactionId(); if(currentTransaction.equals(lastCommitedTransaction)) {return;} Transaction multi = jedis.multi(); multi.set(LAST_COMMITED_TRANSACTION_FIELD, currentTransaction); Set<String> keys = hashtags.keySet(); for (String hashtag : keys) { Long count = hashtags.get(hashtag); //$redis->hIncrBy('h', 'x', 2); //将名称为h的hash中x的value增加2 multi.hincrBy("hashtags", hashtag, count); } keys = users.keySet(); for (String user : keys) { Long count =users.get(user); multi.hincrBy("users",user,count); } keys = usersHashtags.keySet(); for (String key : keys) { Long count = usersHashtags.get(key); multi.hincrBy("users_hashtags", key, count); } multi.exec(); } @Override public void declareOutputFields(OutputFieldsDeclarer declarer) {} }
这个实现很简单,但是在 finishBatch 有一个细节。
... multi.set(LAST_COMMITED_TRANSACTION_FIELD, currentTransaction); ...
在这里向数据库保存提交的最后一个事务ID。为什么要这样做?记住,如果事务失败了,Storm将会尽可能多的重复必要的次数。如果你不确定已经处理了这个事务,你就会多算,事务拓扑也就没有用了。所以请记住:保存最后提交的事务ID,并在提交前检查。
分区的事务 Spouts
对一个 spout 来说,从一个分区集合中读取批次是很普通的。接着这个例子,你可能有很多redis数据库,而tweets可能会分别保存在这些redis数据库里。通过实现 IPartitionedTransactionalSpout ,Storm提供了一些工具用来管理每个分区的状态并保证重播的能力。
下面我们修改 TweetsTransactionalSpout ,使它可以处理数据分区。
首先,继承 BasePartitionedTransactionalSpout ,它实现了 IPartitionedTransactionalSpout 。
public class TweetsPartitionedTransactionalSpout extends BasePartitionedTransactionalSpout<TransactionMetadata> { ... }
然后告诉Storm谁是你的协调器。
public static class TweetsPartitionedTransactionalCoordinator implements Coordinator { @Override public int numPartitions() { return 4; } @Override public boolean isReady() { return true; } @Override public void close() {} }
在这个例子里,协调器很简单。numPartitions方法,告诉Storm一共有多少分区。而且你要注意,不要返回任何元数据。对于 IPartitionedTransactionalSpout ,元数据由分发器直接管理。
下面是分发器的实现:
public static class TweetsPartitionedTransactionalEmitter implements Emitter<TransactionMetadata> { PartitionedRQ rq = new ParttionedRQ(); @Override public TransactionMetadata emitPartitionBatchNew(TransactionAttempt tx, BatchOutputCollector collector, int partition, TransactionMetadata lastPartitioonMeta) { long nextRead; if(lastPartitionMeta == null) { nextRead = rq.getNextRead(partition); }else{ nextRead = lastPartitionMeta.from + lastPartitionMeta.quantity; rq.setNextRead(partition, nextRead); //移动游标 } long quantity = rq.getAvailableToRead(partition, nextRead); quantity = quantity > MAX_TRANSACTION_SIZE ? MAX_TRANSACTION_SIZE : quantity; TransactionMetadata metadata = new TransactionMetadata(nextRead, (int)quantity); emitPartitionBatch(tx, collector, partition, metadata); return metadata; } @Override public void emitPartitionBatch(TransactionAttempt tx, BatchOutputCollector collector, int partition, TransactionMetadata partitionMeta) { if(partitionMeta.quantity <= 0){ return; } List<String> messages = rq.getMessages(partition, partitionMeta.from, partitionMeta.quantity); long tweetId = partitionMeta.from; for (String msg : messages) { collector.emit(new Values(tx, ""+tweetId, msg)); tweetId++; } } @Override public void close() {} }
这里有两个重要的方法, emitPartitionBatchNew ,和 emitPartitionBatch 。对于 emitPartitionBatchNew ,从Storm接收分区参数,该参数决定应该从哪个分区读取批次。在这个方法中,决定获取哪些tweets,生成相应的元数据对象,调用 emitPartitionBatch ,返回元数据对象,并且元数据对象会在方法返回时立即保存到zookeeper。
Storm会为每一个分区发送相同的事务ID,表示一个事务贯穿了所有数据分区。通过 emitPartitionBatch 读取分区中的tweets,并向拓扑分发批次。如果批次处理失败了,Storm将会调用 emitPartitionBatch 利用保存下来的元数据重复这个批次。
NOTE: 完整的源码请见: https://github.com/storm-book/examples-ch08-transactional-topologies (译者注:原文如此,实际上这个仓库里什么也没有)
模糊的事务性拓扑
到目前为止,你可能已经学会了如何让拥有相同事务ID的批次在出错时重播。但是在有些场景下这样做可能就不太合适了。然后会发生什么呢?
事实证明,你仍然可以实现在语义上精确的事务,不过这需要更多的开发工作,你要记录由Storm重复的事务之前的状态。既然能在不同时刻为相同的事务ID得到不同的元组,你就需要把事务重置到之前的状态,并从那里继续。
比如说,如果你为收到的所有tweets计数,你已数到5,而最后的事务ID是321,这时你多数了8个。你要维护以下三个值—— previousCount=5,currentCount=13,以及lastTransactionId=321。假设事物ID321又发分了一次, 而你又得到了4个元组,而不是之前的8个,提交器会探测到这是相同的事务ID,它将会把结果重置到 previousCount 的值5,并在此基础上加4,然后更新 currentCount 为9。
另外,在之前的一个事务被取消时,每个并行处理的事务都要被取消。这是为了确保你没有丢失任何数据。
你的 spout 可以实现 IOpaquePartitionedTransactionalSpout ,而且正如你看到的,协调器和分发器也很简单。
public static class TweetsOpaquePartitionedTransactionalSpoutCoordinator implements IOpaquePartitionedTransactionalSpout.Coordinator { @Override public boolean isReady() { return true; } } public static class TweetsOpaquePartitionedTransactionalSpoutEmitter implements IOpaquePartitionedTransactionalSpout.Emitter<TransactionMetadata> { PartitionedRQ rq = new PartitionedRQ(); @Override public TransactionMetadata emitPartitionBatch(TransactionAttempt tx, BatchOutputCollector collector, int partion, TransactionMetadata lastPartitonMeta) { long nextRead; if(lastPartitionMeta == null) { nextRead = rq.getNextRead(partition); }else{ nextRead = lastPartitionMeta.from + lastPartitionMeta.quantity; rq.setNextRead(partition, nextRead);//移动游标 } long quantity = rq.getAvailabletoRead(partition, nextRead); quantity = quantity > MAX_TRANSACTION_SIZE ? MAX_TRANSACTION_SIZE : quantity; TransactionMetadata metadata = new TransactionMetadata(nextRead, (int)quantity); emitMessages(tx, collector, partition, metadata); return metadata; } private void emitMessage(TransactionAttempt tx, BatchOutputCollector collector, int partition, TransactionMetadata partitionMeta) { if(partitionMeta.quantity <= 0){return;} List<String> messages = rq.getMessages(partition, partitionMeta.from, partitionMeta.quantity); long tweetId = partitionMeta.from; for(String msg : messages) { collector.emit(new Values(tx, ""+tweetId, msg)); tweetId++; } } @Override public int numPartitions() { return 4; } @Override public void close() {} }
最有趣的方法是 emitPartitionBatch ,它获取之前提交的元数据。你要用它生成批次。这个批次不需要与之前的那个一致,你可能根本无法创建完全一样的批次。剩余的工作由提交器 bolts 借助之前的状态完成。
相关推荐
java入门 - 方法的使用网络技术_文件服务器_远程访问_个人应用实践Flask_Fi_1744736795.zip
内容概要:本文深入探讨了光伏系统中用于稳定直流输出电压的关键技术,主要包括最大功率点跟踪(MPPT)算法、Boost升压电路和电池侧电压电流PI双闭环控制。MPPT算法通过实时监测光伏板的电压和电流,调整电路工作状态使光伏板始终处于最大功率点附近。Boost电路负责将光伏板输出的较低电压提升到所需的较高电压水平。而电池侧的电压电流PI双闭环控制系统,则确保电池在充放电过程中保持稳定。文中还提供了具体的Python代码示例,展示了这些技术的实际应用方法。 适合人群:从事光伏系统设计、开发与维护的专业技术人员,尤其是对提高光伏系统效率感兴趣的工程师。 使用场景及目标:适用于需要构建高效稳定的光伏发电系统的场合,旨在通过优化MPPT算法、Boost电路设计和电池管理策略,实现光伏系统直流输出电压的稳定性和可靠性。 其他说明:文中不仅介绍了理论概念和技术细节,还给出了实际编码实例,帮助读者更好地理解和掌握相关技术的应用。此外,强调了各组件之间的协调运作对于整个系统性能的重要性。
基于ssm+jsp的手办商城管理系统:前端 jsp、jquery、bootstrap,后端 maven、springmvc、spring、mybatis;角色分为管理员、用户;集成商品信息、购物车、我的订单、客服、商品管理等功能于一体的系统。 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Tomcat 7.0.73</b> - <b>JDK 1.8</b>
基于springboot的高校教育综合管理系统:前端 html、jquery、layui,后端 maven、springmvc、spring、mybatis;角色分为管理员、老师、学生;集成宿舍管理、教评管理、排课管理、考试管理等功能于一体的系统。 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>JDK 1.8</b>
内容概要:本文介绍了一种基于NCCN(国家综合癌症网络)指南的人工智能工具,用于为乳腺癌患者提供个性化治疗方案。研究提出了两种AI驱动的方法:Agentic-RAG(检索增强生成)和Graph-RAG。Agentic-RAG通过三个步骤选择临床标题、检索匹配的JSON内容并迭代优化推荐,确保治疗建议的准确性。Graph-RAG则将JSON数据转换为文本并通过大型语言模型(LLM)进行总结,再映射成图结构表示关键治疗关系,最终生成推荐。实验结果显示,Agentic-RAG实现了100%的指南依从率,无幻觉或错误治疗;Graph-RAG达到95.8%的依从率,仅有一例错误治疗。两者均提供了详细的治疗建议,并引用了具体的NCCN文档页码。; 适合人群:从事肿瘤学研究和临床工作的医生、研究人员以及对AI在医疗领域应用感兴趣的科技工作者。; 使用场景及目标:①帮助医生快速获取符合NCCN指南的个性化乳腺癌治疗方案;②提高医生对复杂治疗指南的理解和应用效率;③支持临床决策,确保治疗方案的准确性和透明度。; 其他说明:研究强调了Agentic-RAG和Graph-RAG在处理复杂医学指南方面的优势,特别是在提供详细、可追溯的治疗建议方面。未来的工作将扩展测试范围,涵盖更多类型的癌症,并评估系统在实际临床环境中的表现。此外,系统与电子健康记录(EHR)的集成将进一步提升其临床应用价值。
内容概要:本文详细介绍了K-Medoids聚类算法的MATLAB实现,涵盖了数据导入、算法核心逻辑、可视化展示等多个方面。首先,通过鸢尾花数据集展示了如何导入数据并进行初步处理。接着,深入讲解了K-Medoids算法的关键步骤,如选择初始medoids、计算距离矩阵、分配样本到最近的medoid以及更新medoids。文中还强调了该算法相较于K-Means的优势,即对异常点更为稳健。最后,通过可视化手段展示了聚类结果,帮助读者更好地理解和验证算法的效果。 适合人群:具有一定MATLAB编程基础的研究人员、数据科学家和机器学习爱好者。 使用场景及目标:适用于需要对数据进行稳健聚类分析的场景,特别是当数据集中可能存在异常点时。目标是通过实际案例和代码实现,帮助读者掌握K-Medoids算法的工作原理及其应用场景。 其他说明:文中提供了详细的代码片段和解释,便于读者动手实践。同时提醒了一些常见的注意事项,如初始medoids的选择和距离矩阵的计算效率等问题。
基于springboot的学生选课管理系统:前端 vue2、elementui,后端 maven、springmvc、spring、mybatis;角色分为管理员、学生、老师;集成课程信息、校园论坛、校园公告、选课等功能于一体的系统。 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Node 14.14.0</b> - <b>JDK 1.8</b>
基于ssm的物流快递管理系统:前端 jsp、jquery、easyui,后端 springmvc、spring、mybatis;角色分为管理员、用户;集成在线下单、新闻资讯、订单管理等功能于一体的系统。 ## 功能介绍 ### 网站前台 - 网站首页:主导航栏,轮播图,新闻资讯,服务介绍 - 在线下单:填写发货人和收货人信息,提交订单,按快递单号查询快递明细 - 新闻资讯:资讯信息列表展示,资讯详情 ### 管理后台 - 菜单管理:菜单信息的增删改查 - 角色管理:角色信息的增删改查,编辑权限 - 用户列表:用户信息的增删改查,角色分配 - 新闻管理:新闻信息的增删改查,新闻内容支持富文本编辑 - 留言列表:列表信息的列表查询,信息删除,信息编辑,按姓名和联系方式模糊查询 - 订单管理:订单信息的增删改查,多条件查询,更新订单状态 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Tomcat 7.0.73</b> - <b>JDK 1.8</b>
内容概要:本文档《Dify_实战指南.pdf》介绍了Dify这一多合一的数据处理与分析平台,旨在简化AI应用开发流程。Dify通过提供可视化的界面和模块化设计,支持多种大语言模型,具备私有化部署与数据安全保障,拥有活跃的开发者社区。文档详细阐述了Dify的设计初衷、核心理念、应用场景、主要功能及其开发实战案例,如聊天助手、企业知识库和小红书运营工作流。; 适合人群:具备一定编程基础,对AI应用开发感兴趣的开发者、数据科学家及技术爱好者。; 使用场景及目标:①简化AI应用开发流程,支持多种大语言模型;②提供模块化设计与功能组件,实现快速迭代与创新;③确保数据安全,支持私有化部署;④通过实战案例掌握Dify的实际应用技巧。; 其他说明:文档强调Dify的开源特性、低代码/无代码开发、全面模型支持、功能组件丰富等特点,鼓励开发者利用Dify的工具和社区资源,降低AI应用开发门槛,加速从概念到产品的转化过程。
基于树莓派的微信机器人
基于ssm+jsp的虚拟商品管理系统:前端 jsp、jquery,后端 maven、springmvc、spring、mybatis;角色分为管理员、用户;集成促销商品、商品购买、购物车、订单查询等功能于一体的系统。 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Tomcat 7.0.73</b> - <b>JDK 1.8</b>
内容概要:本文详细介绍了基于二自由度横摆动力学模型的模型预测控制(MPC)在自动驾驶路径跟踪中的应用,特别是针对双移线和单移线路径的跟踪。首先,文章解释了如何自定义期望轨迹并导入轨迹数据,接着讨论了Q矩阵和R矩阵的作用以及如何调整它们以优化侧向位置跟踪和前轮转角曲线的效果。此外,还探讨了输出值边界的约束设置,确保系统的稳定性和可行性。最后,文章提到了模型的仿真效果,并分享了一些实战经验和参数调整技巧,如预测时域的选择和曲率补偿的应用。 适合人群:从事自动驾驶研究的技术人员、对路径跟踪算法感兴趣的工程师和研究人员。 使用场景及目标:适用于自动驾驶汽车的研发过程中,特别是在路径规划和控制模块的设计阶段。目标是提高路径跟踪的精确度和平滑性,确保车辆能够在复杂路况下安全行驶。 其他说明:文中提供了多个代码示例,帮助读者更好地理解和实现MPC控制。同时,推荐观看UP主‘阿Xin自动驾驶’的相关视频,以便直观了解仿真效果。
基于ssm的校园二手交易平台管理系统:前端 jsp、jquery,后端 maven、springmvc、spring、mybatis;角色分为管理员、用户;集成商品浏览、商品详情、在线购买、订单查询等功能于一体的系统。 ## 功能介绍 ### 管理员 - 物品分类管理:分类信息的增删改查,一级分类,二级分类 - 物品管理:用户发布的二手商品信息,后台管理员可以查看,删除商品,上架和下架操作 - 订单管理:用户在线购买商品后,管理员可以查询订单信息,订单删除,订单状态 - 用户管理:用户在前台自行注册的用户账号信息,管理员可以删除、禁用、激活 ### 用户 - 基本功能:登录,注册,退出 - 网站首页:全局搜索,分类导航,商品列表展示 - 商品:商品详情,商品收藏,联系卖家,物品留言,在线购买 - 发布商品:用户可以将自己闲置的二手商品发布到平台上进行售卖 - 我的:用户信息查看与修改,修改头像,密码修改,我收藏的物品,我发布的物品,我的订单 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Tomcat 7.0.73</b> - <b>JDK 1.8</b>
内容概要:本文详细介绍了基于西门子S7-200 PLC的两台水泵一用一备自动控制系统的设计与实现。主要内容包括:1. 控制要求拆解,如总启动和总停止、一用一备交替工作、故障切换与报警、故障判断逻辑;2. 代码实现,涉及变量定义、总启动与总停止逻辑、电机交替运行逻辑、故障切换与报警逻辑;3. 上位机组态源程序,使用WinCC flexible进行画面设计和运行测试。通过这些内容,构建了一个能够稳定运行、具备故障自恢复能力的水泵控制系统。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉PLC编程和上位机组态的从业者。 使用场景及目标:适用于需要高可靠性和冗余备份的工业水泵控制系统,旨在提高系统的稳定性和安全性,减少设备损耗,延长使用寿命。目标是在工业环境中实现无人值守的自动化控制。 其他说明:文中提供了详细的编程思路和具体代码片段,帮助读者更好地理解和应用。此外,还提到了实际调试中遇到的问题及其解决方案,为实际工程应用提供宝贵的经验。
内容概要:本文详细介绍了基于Cruise2019和Matlab2018a构建的燃料电池汽车功率跟随仿真模型。该模型通过多个控制模块确保燃料电池输出功率紧密跟随车辆需求,同时保持电池SOC稳定。具体包括:DCDC控制模块采用动态电压补偿策略,避免电压震荡;再生制动模块在高SOC时增加回收力度,减少机械制动磨损;机械制动与再生制动的无缝切换策略;以及针对燃料堆响应延迟的加速补偿措施。此外,文中还分享了多项调试经验和优化技巧,如变步长求解器的选择、虚拟CAN信号采集点的应用等。 适合人群:从事新能源汽车研究的技术人员、高校相关专业师生、对燃料电池汽车感兴趣的科研工作者。 使用场景及目标:适用于燃料电池汽车的动力系统仿真研究,旨在提高仿真精度,优化控制策略,缩短开发周期。 其他说明:文中提供的代码片段和调试经验对于理解和改进燃料电池汽车的功率跟随性能具有重要参考价值。
基于ssm+vue的校园购物网站管理系统:前端 vue、elementui,后端 maven、springmvc、spring、mybatis;角色分为管理员、用户;集成商品浏览、购物车、在线结算、订单查询等功能于一体的系统。 ## 功能介绍 ### 用户 - 基本功能:登录,注册,退出 - 网站首页:主导航栏,轮播图,商品搜索,商品信息推荐,商品资讯 - 商品购买:商品列表展示,按商品名称和品牌模糊搜索商品,商品详情,购物车,积分兑换,在线结算 - 其他功能:商品资讯,留言反馈 - 个人中心:个人信息查询与修改,密码修改,我的订单查询,我的地址维护,我的收藏列表,用户充值 ### 管理员 - 用户管理:用户信息的增删改查,用户可以在用户端自行注册 - 商家管理:商家信息的增删改查 - 商品分类管理:分类信息的增删改查 - 商品信息管理:商品信息的增删改查,商品图片上传 - 订单评价管理:订单评价信息的列表查询,删除 - 留言板管理:用户在用户端发布的留言信息,管理员后台查看与回复 - 系统管理:轮播图信息的增删改查,商品资讯的增删改查 - 订单管理:订单的列表查询,发货操作 ## 环境 - <b>IntelliJ IDEA 2021.3</b> - <b>Mysql 5.7.26</b> - <b>Tomcat 7.0.73</b> - <b>Node 14.14.0</b> - <b>JDK 1.8</b>
内容概要:本文详细介绍了四旋翼飞行器的仿真与控制技术,涵盖了多个关键技术环节。首先讨论了定高控制,通过PID控制器实现稳定的高度保持。接着介绍了自由落体仿真,展示了如何通过运动学公式进行高度随时间变化的模拟。随后讲解了动力学模型的线性化方法,使复杂的非线性方程变得容易处理。接下来探讨了位置环与姿态环的轨迹跟踪控制,分别针对直线轨迹和圆弧轨迹进行了具体实现。此外,还讨论了多点任务控制与轨迹规划,以及风阻力模型的影响。最后介绍了状态观测器的设计,特别是卡尔曼滤波器的应用,以提高飞行器状态估计的准确性。 适合人群:对四旋翼飞行器仿真与控制感兴趣的科研人员、工程师和技术爱好者。 使用场景及目标:适用于希望深入了解四旋翼飞行器控制原理的研究人员,以及从事无人机开发的技术人员。目标是掌握从理论公式推导到代码实现的全过程,提升对四旋翼飞行器控制系统的理解和应用能力。 其他说明:文中提供了大量具体的代码示例,帮助读者更好地理解和实践相关概念。同时,强调了各控制环节之间的相互关联,确保系统整体的稳定性和可靠性。
内容概要:本文详细介绍了将西门子博图WinCC的历史数据存储到SQL Server数据库的方法及其可视化展示的技术方案。首先,文章讲解了如何创建并配置SQL Server数据库,确保其能够接收来自WinCC的关键参数如压力、温度等,并通过定时任务进行数据的循环保存,保持最新的两万条记录。接着,文中提供了具体的C语言、VBS脚本以及SQL语句用于实现从WinCC到SQL Server的数据传输,强调了防止SQL注入攻击的安全措施。此外,针对数据展示部分,分别展示了利用Python的matplotlib库绘制趋势图、C# WinForm应用程序以及ASP.NET结合Highcharts进行实时数据可视化的多种方法。同时,文章还提到了一些常见的实施过程中可能遇到的问题及解决方案,例如数据库连接超时、数据量过大导致的性能下降等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些熟悉西门子博图WinCC平台并对SQL Server有一定了解的人群。 使用场景及目标:适用于需要将工业生产过程中的重要参数长期保存以便后续分析的企业或机构。主要目的是建立一套高效可靠的数据存储与检索系统,确保数据完整性和可用性的同时,提供直观易懂的数据呈现形式,帮助决策者快速掌握设备运行状况。 其他说明:文中提到的所有代码片段均为简化版,实际应用时需根据具体情况调整参数配置。对于大规模数据处理,建议进一步优化数据库架构和查询语句以提高性能。
内容概要:本文详细介绍了利用改进型D-H参数法建立六轴机械臂模型,并结合3-5-3混合多项式插值和改进粒子群算法(IPSO)优化机械臂轨迹的方法。首先,通过MATLAB机器人工具箱构建机械臂模型并验证其正逆解准确性。然后,针对传统3-5-3多项式插值存在的时间冗余和加速度过高的问题,提出了一种基于改进粒子群算法的时间分配优化方案。该方案通过引入动态惯性权重和指数惩罚函数来平衡最短时间和关节加速度限制之间的关系,最终实现了将原本7秒的任务缩短至5秒的目标,同时提高了末端执行器的轨迹精度。 适合人群:从事机器人技术研究、机械工程领域的研究人员和技术人员,以及对机械臂轨迹规划感兴趣的高校师生。 使用场景及目标:适用于需要提高工业机器人工作效率的应用场合,如自动化生产线中的搬运、焊接等任务。主要目的是通过优化轨迹规划,减少机械臂的动作时间,提升生产效率。 其他说明:文中提供了详细的MATLAB代码示例,便于读者理解和复现实验结果。此外,还讨论了一些常见的调试技巧和注意事项,有助于解决实际应用中可能遇到的问题。
内容概要:本文详细介绍了利用ANSYS-LSDYNA对岩石试件进行循环冲击压缩模拟的研究。重点探讨了预制空节理对应力波传播的影响、重启动技术的应用以及裂纹扩展的累积效应。通过设置不同的材料模型和边界条件,作者成功模拟了岩石在多次冲击下的损伤演化过程,并揭示了裂纹扩展路径的变化规律。此外,还讨论了如何通过后处理手段如Python脚本和LS-PrePost工具来分析和可视化模拟结果。 适合人群:从事岩土工程、材料科学及数值模拟领域的研究人员和技术人员。 使用场景及目标:适用于需要深入理解岩石在循环冲击载荷下的力学行为,特别是在涉及地下工程、矿山开采等领域。目标是提供一种有效的数值模拟方法,帮助预测和预防工程事故。 其他说明:文中提供了详细的K文件配置和Python代码片段,便于读者复现实验结果。同时强调了计算资源管理的重要性,提出了并行计算加速的方法。