ARTS 打卡 第 19 周
ARTS简介
Algorithm 是一道算法题,Review 是读一篇英文文章,Technique/Tips 是分享一个小技术,Share 是分享一个观点。
Algorithm
给定一个字符串 (s) 和一个字符模式 § ,实现一个支持 ‘?’ 和 ‘’ 的通配符匹配。 ‘?’ 可以匹配任何单个字符。 '’ 可以匹配任意字符串(包括空字符串)。 两个字符串完全匹配才算匹配成功。
说明:
s 可能为空,且只包含从 a-z 的小写字母。
p 可能为空,且只包含从 a-z 的小写字母,以及字符 ? 和 *
解题思路: 这道题与10. 正则表达式匹配类似,不过与其相比稍微简单一点,可以考虑使用动态规划求解, 如果我们用d[i][j]来表示s的前i个字符与p的前j个字符是否匹配。
基础条件 d[0][0]肯定匹配
如何确定 d[i][j]是否匹配,如果当前字符相等或p的字符是’?',则dp[i][j]==dp[i-1][j-1]如果p对应的字符是’',则可以分为把当做空字符串(dp[i][j]==dp[i][j-1])与匹配当前位置(dp[i][j]==dp[i-1][j)两种情况考虑,满足其中一种就可以
ps:参考资料
Review
学习-微服务架构模式系列,网站地址是:https://microservices.io 微服务架构-Pattern: Multiple service instances per host 这篇文章的主要介绍了微服务架构下如何进行部署:多实例部署到一台主机 背景:使用微服务架构,会有很多服务,为了获得可用性和吞吐量每个服务发布一组实例 问题:每个服务如何打包和发布
强制条件:
不同服务使用不同的语言、框架
提高吞吐量和可用性,每个服务都可能有多实例
服务必须能够独立部署和扩容
每个服务实例必须与其他实例隔离
每个服务快速打包部署
限制每个服务实例的资源使用情况
监控每个服务实例
可靠的部署
高效的部署
解决方法,多个服务实例部署在一台主机
好处:
资源利用率较高
不足
有资源需求冲突的风险
版本依赖的风险
限制当个服务的资源是困难的
无法单独监控每个服务实例的资源消耗
ps:《微服务架构设计模式》
Tips
记录我对于Linux的学习,备份压缩相关的命令:
ps:“~” 表示为 home 目录,“.” 则是表示目前所在的目录,“…” 则表示当前目录的上一层目录 -h 用人类可读的格式展示(G(千兆字节),M(兆字节),K(千字节)),大部分命令有这个参数
gzip
gzip 用于压缩或解压缩文件,用它压缩文件后,其名称后面会多出".gz"的扩展名 格式:gzip [OPTION]… [FILE]… 常用选项:
-c或–stdout或–to-stdout 把压缩后的文件输出到标准输出设备,不去更动原始文件。
-d或–decompress或----uncompress 解开压缩文件。
-f或–force 强行压缩文件。不理会文件名称或硬连接是否存在以及该文件是否为符号连接。
-l或–list 列出压缩文件的相关信息。
-n或–no-name 压缩文件时,不保存原来的文件名称及时间戳记。
-N或–name 压缩文件时,保存原来的文件名称及时间戳记。
-q或–quiet 不显示警告信息。
-r或–recursive 递归处理,将指定目录下的所有文件及子目录一并处理。
-S<压缩字尾字符串>或----suffix<压缩字尾字符串> 更改压缩字尾字符串。
-t或–test 测试压缩文件是否正确无误。
-v或–verbose 显示指令执行过程。
-<压缩效率> 压缩效率是一个介于1-9的数值,预设值为"6",指定愈大的数值,压缩效率就会愈高。
–best 此参数的效果和指定"-9"参数相同。
–fast 此参数的效果和指定"-1"参数相同。
Share
分享最近对的学习,这次分享的是SpringBoot系列(3)- 快速开发业务代码,可能会有不足之处,之后会根据理解继续修改。
版权声明: 本文为 InfoQ 作者【引花眠】的原创文章。
原文链接:【http://xie.infoq.cn/article/f980850c305727f2310841cf6】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论