@lgh-dev
2018-12-20T08:11:31.000000Z
字数 5468
阅读 939
积云教育
这个问题考核的东西还是比较直接的,基本上都在题面上显示出来了,最主要的还是是我们要把
redis
相关的知识点结合着我们的的项目应用场景融汇贯通的说出来,这样会显得更真实贴切,比如说redis数据类型没必要都说出来,最好是能够说在哪个项目的那个应用场景下使用了什么数据类型,如果全说的话,一是感觉还是在背东西,二是如果忘了的话会比较尴尬;为什么使用的话就可以说一些redis的优点,还有他与memecache的区别去拓展知识面。
- 我在我们之前的项目中使用redis的缓存还是比较多的,为什么使用redis呢,一是相对于memcache来说的话,redis支持的数据类型还是比较多的,我在我之前的项目中使用比较多的还是
string
和list
类型,- 比如我们之前的一个XXX项目前台要展示一些数据统计数据信息,但这个数据查询涉及到多张表的联合查询,如果每次用户访问都要从数据库查的话,那么就会加大数据库的压力,再加上这些统计信息对数据实时性要求不高,所以我们就选择使用了redis缓存,使用
setex
设计缓存数据及过期时间,这样的话,数据访问大部分都会转到redis去请求,- 我还用redis做过简单的
消息队列
,我们之前那个电商的网站后台有个需求就是给用户批量发送营销类的短信,如果采用传统的同步处理的话,如果处理的比较慢,可能会造成网络超时,所以我们采用消息队列这种异步处理,后台上传要发送的用户手机号的信息,获取数据拆分后用lpush
命令redis的list队列中,作为消息队列的生产者,然后再写一个定时脚本定时监听list队列的数据,作为消费者,这样的话实现异步数据的处理。
代码实战的使用场景参考如下
Redis的7个应用场景(PHP实战)
这个问题考核的东西就很直接了,主要的话就是考核你Linux命令使用的熟练程度,我们回答的这种问题的话还是要命令结合着实际的应用来说会更好,显得内容会更加的充实。
-h
或者--help
去查看命令的常用参数有哪些, 1、文本搜索类
如果vi或vim打开一个很大的文件,不易查找到对应的内容。可以用查找命令:
末行模式下输入"/关键字",输入的关键字会高亮显示,按"n"向下查找,按"N"向上查找。
2、管道命令,也就是"|"
将查询出来的内容交给管道后面的命令装饰之后再显示出来
cat -n test.txt|grep "123" //显示123所在行的全部内容
ps -ef | grep php-fpm | wc -l //查看php-fpm的进程总数
3、查看版本
php -v //查看php的版本号信息
4、用户和用户组的权限
useradd April //创建用户
groupadd April //创建用户组
5、find搜索文件和目录
find /home -name helloword* //查找home目录下名为helloword开头的文件或目录
find / -name h?ll*
find / -size +1000k //查找根目录下大于1000k的文件
find 查找效率比较低
查找命令还有:locate,whereis xxx
6、重定向命令
标准输入
命令 < 文件 //把文件作为命令的输入
标准输出
①语法:命令 > 文件 //把命令执行结果输出到文件中
ls -l > list.txt //命令结果输出到list.txt文件中
ls -l > list.txt //命令结果输出到list.txt文件中,list已经存在则覆盖
ls -l >> list.txt
//命令结果输出到list.txt文件中,list已经存在不会覆盖而是直接追加
7、权限修改
这中命令我们还是经常会用到的
chmod -R 755 /home/April/lib //将/home/April/lib文件夹及其里面的权限
chown -R April:April /home/April/lib //将/home/April/lib文件夹及其里面内容的所有者修改为April
8、常用查看系统使用情况的命令
free -m //查看内存使用情况:free -m (m是MB,g为GB)
df -h //查看磁盘使用情况
cat /proc/cpuinfo //查看cpu使用情况
cat /proc/cpuinfo | grep "model name" //只显示一行对应的cpu型号以及其他信息
cat /proc/cpuinfo | grep "model name" | wc -l //统计出一共有多少核
du -h 文件夹名 //查看某文件夹的空间使用情况
du -sh 文件夹名/* //查看某文件夹内的所有文件的大小:
9、SSH登录限制
vi /etc/ssh/sshd_config
PermitRootLogin yes //允许root用户 SSH登录
PermitRootLogin no //不允许root用户 SSH登录
vi /etc/ssh/sshd_config
AllowUsers April //如此设置后,只能用户April 以SSH形式登录,其他用户登录不了
⚠️修改配置后,使用如下命令时期生效
service sshd reload
10、查看Linux的防火墙
iptables -vnL | grep ":80" //防火墙是否阻止80端口
其他命令参照:
Linux21个常用命令-思否
这个问题回答最主要的就是两个方面,一个就是什么是跨域,用自己的话能给别人解释清楚,然后说才是你在项目的过程中哪儿遇到了跨域的问题,然后你是怎么处理的,跨域问题的处理无非就两端,客户端和服务端两个方面,然后结合实际场景说明什么时候用客户端合适,什么时候用服务端合适.
Ajax跨域的原理
举例来说,
http://www.example.com/dir/page.html
这个网址,协议是http://
,域名是www.example.com
,端口是80(默认端口可以省略)。它的同源情况如下。
http://www.example.com/dir2/other.html:同源
http://example.com/dir/other.html:不同源(域名不同)
http://v2.www.example.com/dir/other.html:不同源(域名不同)
http://www.example.com:81/dir/other.html:不同源(端口不同
可以参考 浏览器同源政策及其规避方法(阮一峰)
如何解决跨域的问题
- JSONP之所以能够用来解决跨域方案,主要是因为
<script>
脚本拥有跨域能力,而JSONP正是利用这一点来实现;
客户端网页网页通过添加一个元素,向服务器请求JSON数据,这种做法不受同源政策限制
function addScriptTag(src) {
var script = document.createElement('script');
script.setAttribute("type","text/javascript");
script.src = src;
document.body.appendChild(script);
}
window.onload = function () {
addScriptTag('http://example.com/ip?callback=foo');
}
function foo(data) {
console.log('response data: ' + JSON.stringify(data));
};
请求时,接口地址是作为构建出的脚本标签的src的,这样,当脚本标签构建出来时,最终的src是接口返回的内容
服务端对应的接口在返回参数外面添加函数包裹层
foo({
"test": "testData"
});
由于<script>
元素请求的脚本,直接作为代码运行。这时,只要浏览器定义了foo函数,该函数就会立即调用。作为参数的JSON数据被视为JavaScript对象,而不是字符串,因此避免了使用JSON.parse的步骤。
注意,一般的JSONP接口和普通接口返回数据是有区别的,所以接口如果要做JSONO兼容,需要进行判断是否有对应callback关键字参数,如果有则是JSONP请求,返回JSONP数据,否则返回普通数据
缺点基于JSONP的实现原理,所以JSONP只能是“GET”请求,不能进行较为复杂的POST和其它请求,所以遇到那种情况,就得参考下面的CORS解决跨域了
CORS处理
PHP后台配置跨域问题很简单
<?php
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept');
//主要为跨域CORS配置的两大基本信息,Origin和headers
也就是在header头里面这是允许访问的域名来源地址即可,比如在laravel作为框架的服务端的话,这段代码就可以放到laravel的中间件中。
这个问题其实回答的时候最主要的还是要把这三个框架的特点都能够说清楚,然后能从中找出来区别,比较他们之间的优缺点,也没有必要非得说哪个框架好,那个框架不好,最终话题还是落到自己擅长的框架上,多说一些自己比较擅长的框架的特点。
我在项目的开发中使用比较多的框架是laravel和tp,laravel主要用过
5.2
和5.5
的版本,Tp主要使用的是3.2
的版本
个人认为的话相对于Tp的话,laravel更符合现代PHP的标准,
支持composer的包管理工具,代码的封装性体现的更好一些,安全性也会更好,比如Laravel在提交表单时需要在表单中加入{csrf_field}来防止跨域攻击,而TP3.2没有;
laravel的必须先定义路由才能访问,路由功能也比较丰富,可以定义路由的固定访问方式,比如get,post等,路由还可以进行分组,添加路由访问的前缀活着中间件的限制等
我在项目中也使用过一些laravel的特性,我在之前的项目中也用到了一些laravel的特性,比如中间件,数据迁移,任务调度等,感觉这些特性还是比较实用的,比如说任务调度吧,像之前的话在tp框架里面我们定义计划任务,要提前写好要执行的脚本,然后在crontab中定义好要执行的脚本,但是在laravel的中的话,可以使用自定义控制台,然后在控制台的kernel中配置好执行artisan命令列表,用任务调度命令驱动即可
当然的话我觉得tp3的话也有他自己的一些特点,他更易于上手,有着丰富的中文文档,学习的成本也比较低,比较适合中小型项目的开发,但是个人感觉他的目录比较混乱,控制器层渲染视图相对来说没有laravel和Yii框架那么灵活,对ajax的支持感觉不是太好,最近自己也自学过tp5,感觉跟之前的版本相差还挺大的,也引入了composer,里面的一些validate的验证挺像laravel的,自己学的话应该也特别容易上手。
相对于上面两个框架,个人感觉Yii框架是纯OOP思想的框架,开发速度和运行速度比较快,他的模块使用会比较方便,命令行gii一键生成代码使用也还可以,但是感觉后面跟的参数必须得是命名空间的全路径,相对来说感觉没有laravel框架的自动生成代码更加的方便,yii框架的文档对model层的说明比较少,文档实例感觉没有tp和laravel那么多,最主要的话感觉视图层感觉比较混乱,涉及了比较多的php代码,但是个人感觉这样的设计也会使得视图渲染的更加快速
这三个框架本人感觉都是比较优秀的框架,也是使用率比较高的框架,总的来说个人觉得laravel框架的代码比tp和Yii更加的符合现在PSR的标准,但是相对来说laravel的代码比较臃肿,个人建议如果做中小型的项目建议选择tp,如果做大型项目的话建议还是使用Yii框架或者laravel框架比较适合。